Kategorie
KI-Agenten
Artikel teilen
Jeder Anbieter von KI-Agenten behauptet, sein Produkt würde „lernen“. Die meisten von ihnen beschreiben damit lediglich Prompt-Caching, das mit einem entsprechenden Marketing-Budget beworben wird.
Die Lücke zwischen dem Anspruch auf Selbstlernen und der tatsächlichen Umsetzung ist derzeit eine der größten im Bereich der Unternehmens-KI. Gartner schätzt, dass bis 2027 über 40 % der Projekte mit agentenbasierter KI abgebrochen werden, wobei „Agent-Washing“ ein wesentlicher Treiber sein wird. Nur etwa 130 von Tausenden von Anbietern, die agentenbasierte KI entwickeln, bauen etwas wirklich Neues. Der Rest benennt lediglich Chatbots und RPA um.
Beim Selbstlernen wird diese Diskrepanz am deutlichsten. Was ist also tatsächlich nötig, um einen KI-Agenten zu entwickeln, der in der produktiven Umgebung im Laufe der Zeit immer besser wird – und das nicht nur in einer Demo?
Das Problem der Feedback-Erfassung
Selbstlernen beginnt mit Feedback. Das klingt offensichtlich, aber die technische Herausforderung besteht nicht in der Erfassung von Feedback an sich. Es geht darum, das richtige Feedback in der richtigen Detailtiefe zu erfassen.
Wenn ein Nutzer einem Agenten mitteilt: „Das ist falsch“, ist dieses Feedback zwar ehrlich, aber unpräzise. In einem Workflow mit 15 Nodes könnte „Das ist falsch“ bedeuten, dass die Datenextraktion fehlgeschlagen ist, die Klassifizierungslogik fehlerhaft war oder die Formatierung der finalen Ausgabe nicht stimmte. Wenn Sie dieses Feedback dem falschen Node zuweisen, zieht der Agent die falsche Lehre daraus und wird schlechter statt besser.
Die meisten Plattformen überspringen dieses Problem völlig. Sie erfassen Daumen-hoch/Daumen-runter-Bewertungen auf Aufgabenebene und nennen das eine Feedbackschleife. Aber Feedback auf Aufgabenebene ohne Routing auf Node-Ebene ist so, als würde man einem Koch sagen „Das Essen war schlecht“, ohne zu präzisieren, ob das Steak übergart oder die Sauce misslungen war. Beim nächsten Mal erhalten Sie ein völlig anderes Gericht, aber kein besseres.
Der Aufbau einer echten Feedback-Infrastruktur bedeutet, drei Probleme gleichzeitig zu lösen: die Erfassung des Nutzerfeedbacks in natürlicher Sprache, die Zuordnung dieses Feedbacks zu dem spezifischen Workflow-Schritt, der das Problem verursacht hat, und die Speicherung in einer Weise, dass das System beim nächsten Durchlauf darauf reagieren kann. Jedes dieser Probleme ist ein eigenständiges Entwicklungsprojekt.
Task-to-Node-Mapping: Das große Rätsel, über das niemand spricht
Dies ist der Punkt, an dem die meisten Behauptungen zum Thema Selbstlernen scheitern. Ein Nutzer sagt: „Die Kandidaten-Übereinstimmung stimmt nicht“, und Ihr System muss herausfinden, ob der Lebenslauf-Parser, das Scoring-Modell, der Ranking-Algorithmus oder das finale UI-Präsentations-Layer das Problem verursacht hat.
Der naive Ansatz besteht darin, den Nutzer zu bitten, genau anzugeben, welcher Schritt fehlerhaft war. Das funktioniert bei technischen Teams. Es funktioniert jedoch nicht bei Personalmanagern, Controllern oder Betriebsleitern, die den Agenten im Alltag tatsächlich nutzen. Sie denken in Ergebnissen, nicht in Workflow-Schritten.
Die technische Lösung ist eine Mapping-Ebene, die unstrukturiertes Feedback („Dieser Rechnungsbetrag ist falsch“) aufnimmt und durch den gesamten Ausführungs-Graphen zurückverfolgt, um die wahrscheinlichste Fehlerquelle zu identifizieren. Dies erfordert die Aufrechterhaltung eines vollständigen Ausführungs-Traces für jede Aufgabe, den Aufbau eines probabilistischen Modells, das Fehler auf Ergebnisebene bestimmten Nodes zuordnen kann, und eine so hohe Genauigkeit, dass die Korrekturen die Leistung tatsächlich verbessern.
Genau für dieses Problem wurde der Tool Tuner von Beam entwickelt. Er erkennt typische Fehlerfälle – Halluzinationen, leere Ausgaben, falsche Formate –, führt sie auf das spezifische Tool oder den Node zurück, der das Problem verursacht hat, und korrigiert das Verhalten automatisch. Bei 12 produktiven Implementierungen erreichten 10 eine Genauigkeit von über 80 % beim Feedback-to-Node-Mapping. Die verbleibenden zwei lagen bei rund 60 % und 78 %. In dieser Spanne liegt der Großteil der interessanten Entwicklungsarbeit, da sie meist durch uneindeutige Workflows verursacht wird, bei denen mehrere Nodes als Fehlerquelle infrage kommen.
Drift Detection: Der lautlose Killer
Ein Agent, der in der ersten Woche perfekt funktioniert und bis zur achten Woche nachlässt, ist schlimmer als ein Agent, der noch nie funktioniert hat. Bei einem Totalausfall wird zumindest nachgeforscht. Bei einem Drift verschlechtert sich die Ausgabequalität so langsam, dass es niemand bemerkt, bis der Schaden bereits entstanden ist.
Die Analyse von mehr als 4 Millionen produktiven Agenten-Aufrufen zeigt, dass Drift die häufigste Fehlerquelle bei produktiven Agenten ist. Er äußert sich in vier Formen: Compliance-Drift (der Agent hält sich nicht mehr an seine eigenen Regeln), Längen-Drift (Antworten werden im Laufe der Zeit länger oder kürzer), semantischer Drift (die Bedeutung der Ausgaben verschiebt sich allmählich) und Regression (die Leistung bei Aufgaben, die zuvor funktionierten, nimmt ab).
Die Erkennung von Drift erfordert eine kontinuierliche Evaluierung im Vergleich zu Baseline-Metriken, nicht nur ein bloßes Error-Logging. Sie müssen die Verteilung der Ausgaben im Laufe der Zeit verfolgen, statistische Abweichungen signalisieren, bevor sie für den Nutzer sichtbar werden, und automatisierte Rollback- oder Korrekturmechanismen bereithalten. Die meisten Observability-Tools liefern Ihnen lediglich Fehlerraten und Latenzzeiten. Fast keines von ihnen erfasst den semantischen Drift – also genau den Drift, der den geschäftlichen Nutzen zerstört.
Der Aufbau eines Drift-Detection-Systems bedeutet, dass Sie neben Ihrer Produktions-Pipeline eine Shadow-Evaluierungs-Pipeline betreiben müssen. Jede N-te Ausführung wird mit Ihren Baseline-Kriterien abgeglichen, und Abweichungen lösen Alarme aus, noch bevor die Nutzer des Agenten den Leistungsabfall bemerken. Das ist keine glanzvolle Infrastruktur, aber ohne sie wird jedes „Lernen“ Ihres Agenten die Sache mit der gleichen Wahrscheinlichkeit verschlechtern wie verbessern.
Das Kaltstart-Problem
Selbstlernen erfordert Daten. Neue Agenten haben keine. Dies führt zu einem Bootstrapping-Problem: Der Agent benötigt Feedback aus der Produktion, um sich zu verbessern, muss aber in der Produktion bereits gut genug sein, um überhaupt nützliches Feedback zu generieren.
Die übliche Notlösung besteht darin, mit synthetischen Daten oder historischen Beispielen zu trainieren. Das bringt Sie auf ein solides Fundament, aber synthetische Daten haben ihre Grenzen. Echte Produktionsumgebungen weisen Edge Cases, Formatierungsabweichungen und domänenspezifische Besonderheiten auf, die synthetische Daten nicht vorhersehen können. Der Agent wird die 80 % der Standardfälle vom ersten Tag an bewältigen, sich jedoch mit den 20 % der Härtefälle schwer tun, auf die es eigentlich ankommt.
Ein besserer Ansatz ist ein gestaffelter Rollout (Staged Deployment): Starten Sie den Agenten in einem eng umgrenzten Bereich, in dem vorhandene Daten die meisten Fälle abdecken, sammeln Sie Feedback an den Rändern und erweitern Sie den Bereich, sobald sich die Genauigkeit verbessert. Dies erfordert eine Infrastruktur, die dynamische Grenzen und einen schrittweisen Rollout unterstützt – eine weitere Entwicklungsebene, die die meisten Teams nicht einplanen.
Wann man neu trainiert und wann man den Prompt anpasst
Nicht jedes Feedback erfordert ein erneutes Training. Manchmal ist die Lösung eine Prompt-Anpassung. Manchmal ist es eine Konfigurationsänderung. Und manchmal ist es ein echtes Modell-Update. Zu wissen, welche Maßnahme anzuwenden ist, und diese Entscheidung zu automatisieren, ist eine der größten Herausforderungen bei der Entwicklung selbstlernender Agenten.
Der Entscheidungsbaum sieht in etwa so aus: Wenn der Fehler durch fehlenden Kontext verursacht wird, handelt es sich um eine Prompt-Korrektur. Wenn der Fehler durch fehlerhafte logische Schlüsse bei bekannten Eingaben verursacht wird, ist es eine Modell- oder Scoring-Anpassung. Wenn das Fehlermuster mehrere Aufgaben betrifft und sich im Laufe der Zeit verschlimmert, ist das der Auslöser für ein erneutes Training (Retraining).
Genau hier setzt die Auto-Optimierungsebene des Tool Tuners an. Sie schreibt Tool-Prompts automatisch um, wenn es um Klarheit oder Kontext geht, passt Standardparameter an, wenn die Eingaben das Problem sind, und kalibriert die Formatierung der Antworten neu, wenn die Ausgaben von den Anforderungen abweichen. Wichtig ist, dass jede vorgeschlagene Änderung vor dem Live-Gang mit einem Golden Dataset abgeglichen wird. Wenn die Korrektur die Ergebnisse verschlechtert, wird sie nicht ausgespielt. Diese Sicherheitsbarriere ist der entscheidende Unterschied zwischen einem System, das wirklich lernt, und einem System, das sich nur zufällig verändert.
Dies von Grund auf selbst zu entwickeln bedeutet, Fehler in Echtzeit nach ihrer Ursache zu klassifizieren, ein Prompt-Versionierungssystem für A/B-Tests von Änderungen zu unterhalten und eine Retraining-Pipeline aufzubauen, die laufen kann, ohne den Agenten offline zu nehmen. Jedes dieser Elemente ist eine absolute Basisanforderung für echtes Selbstlernen, und der Aufbau von Grund auf nimmt Monate in Anspruch.
Warum die meisten Behauptungen zum Selbstlernen reines Marketing sind
Gartners Bericht vom Mai 2026 über Agent-Washing in der Supply-Chain-Technologie bringt es auf den Punkt: Die meisten Anbieter deklarieren bestehende Automatisierungen einfach als agentenbasiert um. Das gleiche Muster zeigt sich beim Selbstlernen. Wenn ein Anbieter behauptet, sein Agent würde „lernen“, stellen Sie ihm diese Fragen:
Leitet er Feedback an spezifische Workflow-Nodes weiter oder sammelt er nur pauschale Bewertungen auf Aufgabenebene?
Kann er Drift automatisch erkennen oder verlässt er sich darauf, dass Anwender Probleme melden?
Unterscheidet er zwischen Prompt-Korrekturen und Modell-Updates oder behandelt er jedes Feedback gleich?
Wie löst er das Kaltstart-Problem bei neuen Workflows?
Kann er Ihnen die Kurve der Genauigkeitssteigerung im Laufe der Zeit anhand echter Produktionsdaten zeigen?
Wenn die Antwort auf die meisten dieser Fragen vage bleibt, haben Sie es mit Prompt-Caching samt Feedback-Formular zu tun. Nicht mit Selbstlernen.
Wie das Entwicklerteam von Anthropic feststellte, geht es beim Aufbau zuverlässiger Agenten „weniger darum, die richtigen Worte zu finden, sondern vielmehr darum, welche Konfiguration des Kontexts am ehesten das gewünschte Verhalten des Modells erzeugt.“ Selbstlernen ist im Grunde ein Problem des Context Engineerings: die richtigen Informationen aus dem richtigen Feedback zur richtigen Zeit an den richtigen Teil des Systems zu leiten.
Was notwendig ist, um dies selbst zu bauen
Wenn Sie darüber nachdenken, eine selbstlernende Infrastruktur intern aufzubauen, ist hier eine grobe Übersicht dessen, was Sie benötigen:
Feedback-Infrastruktur: Eine Erfassungsebene für strukturiertes und unstrukturiertes Feedback, eine Speicherebene, die Feedback mit spezifischen Ausführungen verknüpft, und eine Routing-Ebene, die Feedback auf Aufgabenebene in Korrekturen auf Node-Ebene übersetzt.
Evaluierungs-Pipeline: Kontinuierliches Scoring anhand von Baseline-Metriken, Drift-Erkennung über mehrere Dimensionen hinweg sowie eine automatisierte Alarmierung mit Rollback-Funktion.
Correction-Engine: Prompt-Versionierung mit A/B-Testing, eine Entscheidungsebene, die Fehler nach ihrer Ursache klassifiziert und den passenden Korrekturtyp auswählt, sowie eine Retraining-Pipeline für Fälle, die Anpassungen auf Modellebene erfordern.
Scope-Management: Dynamische Grenzen, die sich mit zunehmender Genauigkeit erweitern, Infrastruktur für einen gestaffelten Rollout und die Behebung des Kaltstart-Problems durch Bootstrapping mit synthetischen Daten.
Observability: Nicht nur Fehlerraten und Latenzen, sondern auch semantisches Tracking, Überwachung der Ausgabeverteilung und Genauigkeitskurven über alle Produktiv-Deployments hinweg.
Das bedeutet eine Entwicklungszeit von 6 bis 12 Monaten, bevor Sie überhaupt etwas für den Produktiveinsatz Bereites haben – kontinuierliche Wartung mit wachsendem Agenten-Portfolio noch gar nicht eingerechnet. Jeder neue Workflow benötigt sein eigenes Feedback-Routing, eigene Baseline-Metriken und eigene Drift-Grenzwerte.
Oder nutzen Sie eine Plattform, die das bereits bietet
Das ist das Problem, das Beam seit über zwei Jahren löst. Der gesamte Stack für selbstlernende Systeme – Feedback-Routing, Task-to-Node-Mapping, Drift-Erkennung, Prompt-Tuning und gestaffelter Rollout – ist über den Tool Tuner direkt in die Plattform integriert. In einem Produktiv-Deployment steigerte der Tool Tuner die Genauigkeit eines Adressvalidierungs-Agenten durch drei automatisierte Optimierungszyklen ohne jeglichen menschlichen Entwicklungsaufwand von 60,6 % auf 95,7 %. So sieht Selbstlernen aus, wenn die entsprechende Infrastruktur tatsächlich vorhanden ist.
Wenn Sie abwägen, ob Sie eine selbstlernende Infrastruktur selbst bauen oder einkaufen wollen, ist die ehrliche Antwort: Der Eigenbau ist möglich, aber teuer, und die Wartungskosten steigen mit jedem zusätzlichen Agenten. Die Unternehmen, die selbstlernende Agenten am schnellsten in die Praxis überführen, sind diejenigen, die das Rad der Infrastruktur nicht neu erfinden wollen.
Sehen Sie selbst, wie die lernenden Agenten von Beam in der Praxis funktionieren.
