Es gibt gerade zwei Sorten KI-Agent in Produktion. Die erste bemutterst du. Du schraubst am System Prompt, schaust zu wie er an einer neuen Art von Aufgabe scheitert, schraubst nochmal, und der Prompt wird langsam zu einer Wand aus Sonderfällen, die keiner mehr anfassen will. Die zweite Sorte bemerkt den Fehler von selbst, schreibt eine bessere Version des eigenen Prompts, testet diese Version an echter Arbeit und behält sie nur, wenn sie wirklich gewinnt. Der Abstand zwischen den beiden ist das ganze Feld der selbstlernenden Agenten, und dieses Jahr hat es aufgehört, eine Forschungskuriosität zu sein.
Ein selbstlernender Agent ist einfach ein Agent in einer Feedback Loop. Der Agent erledigt eine Aufgabe. Etwas bewertet das Ergebnis. Taucht eine Schwäche oft genug auf, schlägt das System einen neuen System Prompt vor, lässt die alte und die neue Version eine Weile auf echtem Traffic laufen und befördert den Gewinner. Stellt sich die neue Version als schlechter heraus, rollt sie zurück auf die letzte funktionierende. Kein Mensch im Weg, aber auch kein Vertrauenssprung, weil nichts befördert wird, bevor es sich das verdient hat.
So weit die Idee. Der interessante Punkt ist, welcher Baustein wirklich schwer ist.
Der Optimizer wurde dieses Jahr gelöst
Der Baustein, über den alle Paper schreiben, ist der Mutationsschritt: Nimm einen Prompt, der zu schwach läuft, und produziere einen besseren. Jahrelang war die ernsthafte Antwort darauf Reinforcement Learning, das ein Modell aus dünnen numerischen Belohnungen nachjustiert. Das funktioniert, aber es ist teuer, und es presst einen reichhaltigen Fehler in eine einzige Zahl.
2026 hat sich das Feld auf eine andere Antwort geeinigt. GEPA, kurz für Genetic-Pareto, wurde auf der ICLR als Oral angenommen und macht ein unverblümtes Argument: Sprache ist ein reicherer Lehrer als eine skalare Belohnung. Statt Gewichte aus einer Zahl anzustupsen, liest GEPA die tatsächliche Trajektorie eines Laufs, das Reasoning, die Tool Calls und das Ergebnis, reflektiert dann in Klartext darüber, um zu diagnostizieren was schiefging, und schreibt die kleinste Änderung, die es behebt. Es hält eine Pareto-Front aus Kandidaten, die jeweils auf unterschiedlichen Fällen gewinnen, und kombiniert ihre Stärken.
Die Zahlen sind der Grund, warum die Leute aufmerksam wurden. GEPA schlägt GRPO, eine starke Reinforcement-Learning-Methode, im Schnitt um etwa 6 Prozent und in Spitzen um bis zu 20 Prozent, und nutzt dabei bis zu 35x weniger Rollouts. Es schlägt außerdem MIPROv2, das bisherige Arbeitspferd der Prompt Optimization, um mehr als 10 Prozent. Weniger teure Läufe, bessere Ergebnisse, und kein Reinforcement-Learning-Apparat, den man hochziehen muss. Genau diese Kombination ist der Grund, warum GEPA sich schnell verbreitet hat und warum es inzwischen in DSPy steckt, dem populärsten Optimierungs-Framework.
Der Optimizer ist also, für die Praxis, gelöst. Und genau deshalb ist er der leichte Teil.
Der schwere Teil ist alles drumherum
Liest man die GEPA-Arbeit genau, fällt auf, dass sie offline optimiert. Sie nimmt ein Trainingsset, lässt Rollouts dagegen laufen, reflektiert und reicht dir einen besseren Prompt. Was sie nicht tut: dir sagen, ob dieser Prompt sicher genug ist, um ihn vor echte Nutzer zu stellen, ihn auf Live-Traffic beobachten oder ihn rückgängig machen, wenn er nächsten Dienstag leise wieder schlechter wird. Das sind keine Mängel an GEPA. Es ist schlicht eine andere Aufgabe.
Das Team bei Decagon hat aufgeschrieben, was es wirklich brauchte, um GEPA auf einem Produktions-Classifier laufen zu lassen, und dieser Bericht ist für alle, die liefern, nützlicher als das Paper. Drei Erkenntnisse stechen heraus. Das Reflexions-Modell muss ein Frontier-Modell sein. Sie stellten fest, dass kleinere Modelle "bei der Prompt Optimization komplett versagen" (im Original: "completely fail at prompt optimization"), wobei GPT-4o-mini gar keine Änderung produzierte, weil, wie sie es formulieren, Prompt Optimization Reasoning über Reasoning ist. Mehr Daten sind nicht besser. Ihr Sweet Spot lag bei 20 bis 100 Beispielen, und das Hochdrehen auf 500 ließ den Prompt aufblähen, während die Performance fiel: Overfitting auf Randfälle, statt die allgemeine Regel zu lernen. Und die Standard-Implementierung begrenzt die Prompt-Länge nicht, also mussten sie das selbst bauen, bevor ein außer Kontrolle geratener Prompt ihr Context Window auffraß.
Erst danach, nachdem ein Kandidat die Offline-Schwellen geknackt hatte, schickten sie ihn durch einen kontrollierten A/B-Rollout mit echten Kunden und erhöhten den Traffic auf die neue Version schrittweise. Dieser letzte Satz ist der ganze Punkt dieses Artikels. Der Optimizer ist eine Komponente. Drumherum sitzen ein Evaluations-Harness, ein Gate, das entscheidet ob ein Kandidat überhaupt live darf, ein Rollback-Pfad für den Fall dass er es nicht darf, Längen- und Sicherheits-Constraints auf der Mutation und die Verkabelung, die das Ganze online am Laufen hält statt als einmaligen Batch-Job. In dieser umgebenden Schicht steckt die Zuverlässigkeit, und sie ist fast nie das, was ein Paper bekommt.
Die Bausteine einer selbstlernenden Loop
Es hilft, die Teile zu benennen, denn eine Produktions-Loop ist in Wahrheit ein Zusammenbau aus kleinen, langweiligen Jobs, die jeweils genau eine Sache tun.
Ein Scorer, oder Critic, verwandelt ein Ergebnis in eine Zahl. Ein einzelnes LLM, das ein anderes LLM benotet, ist in Richtung des eigenen Stils verzerrt, deshalb ist das robustere Muster mehrere Critics mit unterschiedlichen Kriterien, oder sogar unterschiedliche Modell-Anbieter, die einen Median bilden. Der Score ist nur so vertrauenswürdig wie das Panel, das ihn produziert hat.
Ein Pattern Detector beobachtet die Scores über die Zeit und entscheidet, wann eine echte Schwäche vorliegt, im Gegensatz zu einem einzelnen schlechten Lauf. Das ist der Unterschied zwischen auf Rauschen reagieren und auf einen Trend reagieren.
Der Optimizer ist der GEPA-artige Reflektor, den ich oben beschrieben habe. Er ist der Teil, der den neuen Prompt schreibt, und er ist der Teil, auf den sich alle versteifen.
Ein Safety Gate ist der Erwachsene im Raum. Bevor ein neuer Prompt übernehmen darf, lässt das Gate ihn direkt gegen den Amtsinhaber antreten, prüft, dass die Verbesserung echt ist und kein Münzwurf, und weigert sich, eine Version zu befördern, die über eine Schwelle hinaus schlechter wird. Kombiniere das mit automatischem Rollback und einem Eintrag des letzten funktionierenden Prompts, und eine schlechte Mutation kostet dich ein paar Läufe statt eines Wochenendes.
Ein Experiment Tracker merkt sich jeden Lauf, jeden Score und jede Prompt-Version, damit die Loop ein Gedächtnis hat und damit du nachvollziehen kannst, warum gerade dieser Prompt live ist. Ohne ihn evolvierst du blind.
Keiner davon ist glamourös. Alle sind tragend. Reiß das Gate und das Rollback heraus, und du hast keinen selbstlernenden Agenten, sondern einen Agenten, der seinen eigenen Prompt ohne Sicherheitsgurt mutiert, was ein schlechterer Agent ist als der, mit dem du angefangen hast.
Warum das bisher eine reine Python-Geschichte war
Hier ist die Lücke, die das für mich losgetreten hat. Jeder ernstzunehmende Prompt Optimizer in 2026 ist in Python geschrieben. DSPy, GEPAs eigene Referenz-Implementierung, TextGrad, AdalFlow, Microsofts PromptWizard. Wenn deine Agenten in einem Python-Data-Science-Stack laufen, hast du die Qual der Wahl. Wenn sie in TypeScript laufen, wo ein enormer Anteil der echten Produktions-Agenten tatsächlich lebt, gab es nichts. Keinen dünnen Port, nichts.
Genau diese Lücke füllt darwin-agents. Es ist eine Open-Source-TypeScript-Bibliothek, MIT-lizenziert, die einem Agenten die ganze Loop gibt statt nur des Optimizers: Multi-Model-Critics, A/B Testing, das Safety Gate, automatisches Rollback und Experiment Tracking, mit dem Optimizer als einem austauschbaren Stück darin. Die Design-Wette ist dieselbe wie in diesem Artikel. Der Optimizer ist der Teil, den du aus der Forschung borgen kannst. Die Produktionsschicht ist der Teil, den du selbst bauen musst, also bau die gut und mach den Optimizer steckbar.
Das jüngste Release schließt die naheliegende Loop. Bis jetzt lieferte die Bibliothek einen GEPA-artigen reflektiven Optimizer als etwas, das du selbst aufrufen konntest, und eine separate, durch ein Safety Gate abgesicherte Evolution Loop, aber die beiden waren nicht miteinander verdrahtet. Die Loop nutzte weiter einen einfacheren Optimizer. Die neue Version verbindet sie, sodass der reflektive Optimizer jetzt innerhalb des Produktions-Gates läuft statt als Offline-Skript. Soweit ich es finden kann, gibt es genau diese Kombination, ein GEPA-artiger Optimizer, der Prompts live hinter einem Safety Gate evolviert, in TypeScript, sonst noch nirgendwo. Es ist opt-in, bestehende Agenten verhalten sich also exakt wie vorher, bis du es einschaltest, und es ist immer noch Alpha, also behandle es wie Alpha.
Wer die umgebenden Ideen lieber auf eine ganze Flotte statt auf einen einzelnen Agenten angewendet sehen will: dieselbe Logik taucht in eine ganze Agenten-Flotte ohne Vendor-Rechnung tunen auf.
Wann du das wirklich willst
Selbst-Evolution verdient sich ihre Komplexität, wenn drei Dinge gleichzeitig stimmen. Du hast genug Traffic, dass ein A/B Test in vertretbarer Zeit zu einem Urteil kommt, denn eine Loop, die nie genug Daten sammelt um zu entscheiden, ist nur Overhead. Die Aufgabe hat einen messbaren Begriff von gut, denn ein Critic braucht etwas zum Bewerten. Und die Kosten einer falschen Mutation sind erholbar, was genau das ist, was Gate und Rollback garantieren.
Wenn das nicht stimmt, ist ein selbstlernender Agent das falsche Werkzeug, und ein Mensch, der ab und zu am Prompt schraubt, ist ehrlich besser. Ehrlichkeit über diese Grenze gehört dazu, wenn man die Technik gut einsetzt. Der Fehlermodus dieses ganzen Felds ist ein Team, das automatische Evolution für einen Agenten einschaltet, der zehnmal die Woche gegen ein schwammiges Ziel läuft, und sich dann wundert, warum der Prompt in Unsinn abdriftet. Die Loop ist nur so gut wie das Signal, das sie füttert.
Das Rennen um den Optimizer ist weitgehend vorbei, und GEPA hat es vorerst gewonnen. Die nächsten zwei Jahre echter Arbeit liegen in der Schicht, um die niemand rennt: das Gate, das Rollback, die Evaluation und der unglamouröse Job, das alles sicher am Laufen zu halten, während die Nutzer zusehen. Das ist der Teil, der entscheidet, ob ein selbstlernender Agent eine Belastung ist oder das Zuverlässigste in deinem Stack.
