Die Datenkrise der KI: Simula, Euphan und Hermes im Praxistest

Die Datenkrise der KI: Simula, Euphan und Hermes im Praxistest

Das Paper, das mich letzte Woche alles andere vergessen ließ, handelte nicht von einem neuen Frontier-Modell. Es war kein Benchmark-Leak. Es war eigentlich nicht einmal eine Ankündigung – sondern ein Forschungs-Paper von Google mit einem Titel, der so trocken war, dass die meisten einfach darüber hinweg gescrollt haben: "Orchestrating Synthetic Datasets with Reasoning." Auch ich war kurz davor, weiter zu scrollen.

Dann las ich die Zeile, die sich drei Tage fest in meinem Kopf verankerte: Modelle, die mit synthetischen Daten trainiert wurden, übertrafen manchmal diejenigen, die mit realen Datensätzen trainiert wurden. Nicht: waren gleichauf. Übertrafen sie. In spezialisierten Bereichen – Cybersecurity, juristisches Schlussfolgern, Medizin –, in denen „echte“ Daten entweder durch Datenschutzgesetze abgeschirmt oder schlicht zu teuer zu beschaffen sind, hatte ein Team bei Google ein System entwickelt, das sich zu Trainingsdaten hinargumentierte, die besser waren als das Original.

Dieses Paper – das ein Framework namens Simula vorstellte – ist die eine Hälfte, die ich in diesem Beitrag auseinandernehmen möchte. Die andere Hälfte betrifft das, was OpenAI im selben Zeitraum liefert: Eine Log-Interpretationsoberfläche, die intern ständig „Euphan“ genannt wird, und eine Persistent-Agent-Plattform mit dem Codenamen Hermes, die still und leise in den vorinstallierten Frontend-Modulen von ChatGPT auf den Moment wartet, in dem das Release-Flag gesetzt wird.

Drei Werkzeuge. Eine grundlegende Veränderung. Und diese Veränderung – von der ich behaupte, dass sie das derzeit wichtigste Ereignis in der AI-Welt ist – besteht darin, dass der Engpass sich verschoben hat. Es ist nicht mehr die Rechenleistung. Es ist nicht mal mehr die Modellgröße. Es ist die Datenpipeline, die das Modell speist, die Observability-Schicht, die den Agenten überwacht, und die Runtime, die den Agenten zwischen Sessions am Leben hält. Alle drei sind derzeit kaputt. Alle drei werden – und zwar gleichzeitig – von den beiden Labs angegangen, die am meisten zu verlieren hätten, wenn sie es nicht täten.

Hier ist, was ich herausgefunden habe, als ich tiefer in jede einzelne dieser Komponenten eingestiegen bin – was aktuell ist, was nur Vaporware, und was die Kombination für all jene bedeutet, die 2026 auf diesen Modellen aufbauen wollen.

Warum die Datenkrise schlimmer ist, als die meisten Entwickler ahnen

Die gängige Erzählung über den Fortschritt im Bereich der KI ist eine Skalierungsgeschichte. Größere Modelle, mehr Parameter, mehr Rechenleistung, bessere Ergebnisse. Diese Geschichte funktionierte bis vor etwa einem Jahr. Dann änderte sich etwas – und niemand in der Publikumspresse hat es wirklich bemerkt.

Die Teams, die an der Entwicklung von Frontier-Modellen arbeiten, haben das qualitativ hochwertige Internet aufgebraucht. Nicht in Bezug auf die Menge – Texte gibt es im Internet immer noch genug. Aber das Signal-Rausch-Verhältnis des noch Verfügbaren ist eingebrochen. Die hochwertigen Texte wurden bei frühen Trainingsläufen bereits konsumiert. Was bleibt, ist dupliziert, maschinell generiert oder fachlich zu oberflächlich, um einem Modell wirklich Neues beizubringen.

Bei allgemeinen Chatmodellen wie GPT, Gemini und Claude zeigt sich das als abnehmender Ertrag durch Skalierung. Jede Verdopplung der Trainingstokens bringt eine geringere Verbesserung als die vorherige. Die Kurve beginnt abzuknicken.

In spezialisierten Domänen ist das Problem strukturell anders – und deutlich gravierender. Wer ein Modell trainieren möchte, das beispielsweise wirklich kompetent im Bereich Cybersicherheits-Analysen ist, benötigt Daten, die die tatsächliche Taxonomie von Angriffen, Akteuren, Schwachstellenklassen und Abwehrstrategien abbilden. Diese Daten gibt es – aber sie sind fragmentiert, verteilt auf proprietäre Threat-Intelligence-Feeds, geschlossene Vorfallberichte und das implizite Wissen erfahrener Analysten, die es nie verschriftlichen würden.

Juristische Argumentation? Verschlossen durch Privilegien, hinter Paywalls versteckt oder in länderspezifischen Urteilen vergraben, die von keiner einzigen Quelle sauber aggregiert wurden.

Medizin? Die HIPAA-Vorschriften existieren aus gutem Grund. Genau die Daten, die man fürs Training bräuchte, sind die, die man aus rechtlichen Gründen nicht in großem Maßstab verwenden darf.

Ich habe das selbst erlebt. Wenn ich versucht habe, gängige Modelle dazu zu bringen, Sicherheitslücken in bestimmten Frameworks präzise zu analysieren, liefern sie zwar souverän klingende Antworten – die aber einer Überprüfung nicht standhalten. Nicht weil die Modelle schlecht wären, sondern weil die Trainingsdaten das eigentliche Terrain nicht abdecken. Die Modelle können „Wikipedia-Cybersecurity”, aber nicht die Version, in der ein professioneller Penetration Tester arbeitet.

Das ist die Wand. Und der Weg um die Wand herum – das, woran jedes ernsthafte KI-Labor seit zwei Jahren arbeitet – ist synthetische Daten. Nicht die Version von 2023, in der man GPT-4 gebeten hat, möglichst viele Trainingsbeispiele zu erstellen und auf ein gutes Ergebnis gehofft hat. Sondern die Version von 2026 – das, wofür Simula steht.

Simula: Wie reasoning-first Datengenerierung tatsächlich aussieht

Ich gebe zu, als ich das Simula-Paper zum ersten Mal überflog, dachte ich, es handele sich um eine weitere Variation des Musters "LLM generiert synthetische Beispiele, dann filtert ein LLM sie". Dieses Muster existiert seit 2023 und hat einen bekannten Fehler: Der Generator fällt in eine enge Verteilung von Beispielen zusammen, die zwar vielfältig wirken, tatsächlich aber nur einen schmalen Ausschnitt des Möglichkeitsraums abdecken. Der technische Begriff dafür ist Mode Collapse, und das ist der Grund, warum die meisten synthetischen Datenpipelines trotz Millionen generierter Beispiele leise hinter Echtdaten zurückbleiben.

Simula ist nicht so. Die Architektur ist tatsächlich anders, und genau darin liegt der interessante Performance-Gewinn. Hier ist der tatsächliche Mechanismus, in der Reihenfolge, wie das Framework ihn durchführt.

Schritt eins: Strukturierte Domänenkartierung. Bevor irgendetwas generiert wird, konstruiert Simula eine hierarchische Taxonomie der Ziel-Domäne. Für Cybersecurity umfasst diese Taxonomie Angriffstypen (Phishing, Injection, Supply Chain, Social Engineering, etc.), Bedrohungsakteur-Kategorien (Nationalstaat, organisierte Kriminalität, Hacktivisten, Insider), Verwundbarkeitsklassen (Buffer Overflow, Logikfehler, Race Condition, Fehlkonfiguration) und Abwehrstrategien. Jeder Zweig hat Unterzweige. Die Taxonomie ist die Landkarte dafür, wie gute Abdeckung aussieht.

Dieser Schritt allein bedeutet mehr Struktur, als die meisten synthetischen Datenpipelines besitzen. Die meisten Pipelines gehen davon aus, dass das Generatormodell von selbst vielfältige Beispiele produziert. Das tut es nicht. Es produziert Beispiele, die auf dem überrepräsentiert sind, was in den eigenen Trainingsdaten dominiert hat.

Schritt zwei: Gesteuertes Sampling. Anstatt dem Generator zu erlauben, Themen zufällig auszuwählen, sampled Simula gezielt über die gesamte Taxonomie hinweg. Wenn Cybersecurity 400 Knoten hat, sorgt der Sampler dafür, dass jeder Knoten angemessen repräsentiert wird – auch die seltenen, komplexen Fälle, die ein zufälliger Sampler vielleicht nur einmal in zehntausend Beispielen trifft. Das ist das Gegenmittel zum Mode Collapse. Man kann nicht in eine enge Verteilung kollabieren, wenn der Sampler einen explizit dazu zwingt, den ganzen Raum abzudecken.

Schritt drei: Metaprompt-Generierung. Jetzt wird Simula interessant. Das System generiert nicht direkt Trainingsbeispiele. Es erzeugt Prompts, die Trainingsbeispiele generieren. Diese Metaprompts enthalten Einschränkungen bezüglich Format, Schwierigkeitsgrad, Perspektive und Argumentationstiefe. Die Metaprompt-Ebene bringt eine Variation ins Spiel, die ein Direktgenerationssystem nicht bieten kann, weil bereits die Metaprompts selbst vielfältig sind.

Man sollte sich den Unterschied klarmachen. Direkte Generierung: "Schreibe ein Cybersecurity-Q&A über SQL-Injection." Man bekommt tausend Varianten im Kern derselben Antwort. Metaprompt-Generierung: "Erstelle zwanzig verschiedene Promptvorlagen, die jeweils ein hochwertiges Trainingsbeispiel zu SQL-Injection hervorrufen – eines aus Sicht eines Incident Responders, eines als Code Review, eines als Compliance Audit, eines als Red-Team-Report, eines als erstes Erlebnis eines Junior Engineers etc." Der Generator produziert Vielfalt im Ansatz, nicht zufällig.

Schritt vier: Komplexitätsparametrisierung. Simula behandelt Komplexität als eigene Achse getrennt von Diversität. Man kann einfache Beispiele über die gesamte Taxonomie generieren, oder komplexe Beispiele über die gesamte Taxonomie, oder eine gezielte Mischung. Die Google-Forscher berichteten, dass das Hochregeln des Komplexitätsparameters einen Performance-Boost um bis zu 10 % bei mathematischen Reasoning-Benchmarks brachte – vorausgesetzt, das zugrundeliegende Generatormodell war stark genug, diese Komplexität auch zu handhaben. Schwache Generatoren, bei denen die Komplexität hochgedreht wurde, lieferten plausibel wirkende, aber falsche Beispiele in großer Zahl – was dem Student-Modell aktiv schadete.

Das ist ein entscheidender Vorbehalt. Komplexität ist ein Multiplikator, keine Lösung. Sie vervielfacht die Qualität des Generators – in beide Richtungen.

Schritt fünf: Duales Kritiker-Qualitätskontrollsystem. Jedes generierte Beispiel wird von zwei Evaluatoren geprüft. Der erste fragt: "Ist das korrekt?" Der zweite fragt separat: "Ist das falsch?" Die Formulierung ist hier entscheidend. Zweimal dieselbe Kritikerfrage stellt, führt zu korrelierten Antworten. Die zweite Evaluation als Widerspruch zu formulieren, erzwingt eine unabhängige Beurteilung. Die beiden Antworten werden zu einem Validierungsscore kombiniert. Nur Beispiele, die beide Filter bestehen, überleben. Beispiele, die ein Kritiker als korrekt und der andere als inkorrekt einstuft, werden zur Überprüfung markiert. Diese Zwei-Fragen-Struktur fängt gerade die plausibel-falschen Ausgaben auf, die Systeme mit Einzelkritiker übersehen.

Das Team testete diese Pipeline mit Gemini 2.5 Flash als Lehrermodell und Gemma-3 4B als Studentenmodell, generierte bis zu 512.000 Datenpunkte pro Domäne und evaluierte in fünf Fachgebieten. Das Kernergebnis – dass synthetische Daten in spezialisierten Bereichen reale Daten erreichten oder übertrafen – hielt in mehreren Evaluationsrunden stand.

Der ehrliche Vorbehalt, den das Paper macht (den auf Twitter niemand zitiert): Es gibt keine einzelne optimale Konfiguration. Die Beziehung zwischen "guten" synthetischen Daten und nachgelagerter Modellperformance ist laut der Forscher tief idiosynkratisch. Unterschiedliche Bereiche benötigen unterschiedliche Komplexitätsmischungen, unterschiedliche Taxonomietiefen, unterschiedliche Kritikergewichtungen. Simula liefert die Regler – sagt aber nicht, wo sie stehen sollten.

Aber der Punkt ist nicht, dass Simula eine Allzwecklösung ist. Der Punkt ist: Das Paradigma hat sich verschoben. Die Frage war früher: "Wie viele Daten kannst du sammeln?" Die Frage ist jetzt: "Wie gut kannst du die Daten gestalten?" Die Gewinner der nächsten Welle spezialisierter KI werden nicht die Labore mit den meisten Crawlern sein. Es werden die Labore mit den besten Taxonomen sein.

Euphan: Warum OpenAI Still und Leise einen Log-Viewer Entwickelte

An dieser Stelle muss ich kurz innehalten, denn das zweite Tool in dieser Geschichte benötigt Kontext, den das erste nicht brauchte.

Wenn Sie noch nie ein agentenbasiertes KI-System gebaut haben, klingt das Konzept eines „Logs“ wahrscheinlich nach etwas, das Sie in einem Datacenter-Dashboard finden würden. Etwas Langweiliges. Etwas, das Ops-Leute interessiert. Lassen Sie mich dieses Bild korrigieren, denn es ist auf eine Weise falsch, die Entwicklern wirklich Zeit kostet.

Ein Agent, der selbst nur eine mäßig komplexe Aufgabe ausführt – beispielsweise zu einem Thema recherchiert, strukturierte Daten extrahiert, einen Entwurf schreibt und diesen irgendwo veröffentlicht –, generiert ein Log, das nichts mit einem klassischen Server-Log gemeinsam hat. Es handelt sich um einen verschachtelten Baum aus Tool-Calls, Modellantworten, Reasoning-Traces, Zwischenoutputs, Wiederholungsversuchen, Berechtigungserteilungen und Statusübergängen. Ein Agent-Durchlauf kann Tausende Zeilen JSON produzieren. Das meiste davon ist Rauschen. Ein kleiner Prozentsatz erzählt die eigentliche Geschichte darüber, was der Agent getan hat und warum.

Wenn ein Agent sich dann fehlverhält – und das geschieht bei allen irgendwann –, ist es Ihre Aufgabe als Entwickler, den Punkt im Log zu finden, an dem das Reasoning schiefging. In einem gut strukturierten Log ist das mühsam. In einem rohen JSON-Dump bedeutet das stundenlanges Scrollen. Ich habe ganze Abende damit verbracht, Agent-Logs zu durchforsten, um zu verstehen, warum ein Tool-Call, der hätte ausgelöst werden sollen, es nicht tat – oder warum ein Modell einen Parameter halluzinierte, der im Prompt gar nicht vorkam.

Genau dieses Problemfeld hat OpenAI still und leise adressiert. Der interne Name, der kursiert, ist Euphan, auch wenn die Firma öffentlich die meisten Features bereits über das Agents SDK Tracing Dashboard und die neue Workspace-Agents-Oberfläche in ChatGPT ausgeliefert hat. Wie auch immer man das zugrunde liegende System nennt: Seine Aufgabe ist klar und wichtig. Es nimmt rohe Agent-Logs und verwandelt sie in etwas, das Menschen schnell lesen können.

Konkret bedeutet das:

• Sauber strukturierte Zeitachsen. Anstelle von verschachteltem JSON bekommen Sie eine lineare Abfolge von Schritten, jeweils mit eindeutiger Rollen-Kennzeichnung (Planner, Retriever, Tool-Caller, Responder), Zeitstempel und einer einzeiligen Zusammenfassung. Jeder Schritt lässt sich aufklappen, um alle Details zu sehen. So finden Sie durch schnelles Überfliegen der Timeline den entscheidenden Wendepunkt.
• Rollen- und Tool-Inspektion. Jeder Tool-Call zeigt, welcher Agent ihn ausgelöst hat, welche Parameter übergeben wurden, was zurückkam und wie lange es dauerte. Wenn ein Tool nach vierzig Minuten einen 429-Rate-Limit-Fehler zurückgibt, hebt die Timeline das hervor – ohne dass Sie erst alles durchsuchen müssen.
• Sichtbarkeit der Entscheidungsfindung. Moderne Agenten emittieren Reasoning-Traces – die interne Begründung des Modells für die Wahl einer Aktion gegenüber einer anderen. Eine verständliche Log-Oberfläche rendert diese Traces als Inline-Anmerkungen zur Timeline, sodass Sie nicht nur sehen, was der Agent getan hat, sondern auch, warum er es für die richtige Entscheidung hielt.
• Direkte Log-Bearbeitung. Das hat mich am meisten überrascht. Sie können einen Log-Eintrag bearbeiten, den modifizierten Zustand speichern und den Durchlauf ab diesem Punkt erneut abspielen. Es ist wie git rebase für Agenten-Historien. Ich habe das sonst noch nirgends sauber gelöst gesehen.
• Filtering, Suche und Metadaten-Abfragen. Bei Durchläufen, die sich über Stunden und Tausende Schritte erstrecken, reicht grep nicht aus. Sie brauchen strukturierte Abfragen. „Zeige alle Tool-Calls mit status != 200.“ „Zeige die Reasoning-Traces, in denen das Confidence-Level unter 0,6 gefallen ist.“ Diese Ebene existiert.

Warum ich immer wieder auf dieses Tool zurückkomme, obwohl es weniger glamurös daherkommt als ein neues Frontier-Modell? Es löst ein echtes Problem, das mich jede Woche beschäftigt. Als ich meinen persönlichen Agent-Stack mit dem Anthropic Agent SDK gebaut habe, war das Schwierigste am Ende nicht das Schreiben des Agents – sondern das Debugging, wenn er sich fehlverhielt. Am Ende bastelte ich mir einen improvisierten Log-Viewer in einer Notion-Datenbank, weil ich kein rohes JSON mehr lesen wollte. Hätte ich damals etwas wie Euphan – oder eine vergleichbare Oberfläche für Anthropic-Logs – gehabt, wäre ich eine Woche früher fertig gewesen.

Das ist Entwickler-Infrastruktur. Kein Consumer-Feature. Keine Keynote-Demo. Aber die Teams, die produktive Agenten ausliefern, werden sich an Log-Interpretations-Tools als das Moment erinnern, in dem der gesamte Workflow beherrschbar wurde.

Und jetzt zum dritten Puzzlestück.

Hermes: Der Wandel vom Chatbot zum immer präsenten Teammitglied

Hermes ist der Codename, der in den letzten Wochen aus den internen Builds von OpenAI geleakt wurde, und ich möchte an dieser Stelle vorsichtig sein, denn es gibt Namensverwirrung auf dem Markt. Die Open-Source-Community hat bereits ein Tool namens Hermes Agent von Nous Research – ich habe darüber geschrieben, wie man es mit OpenClaw in einem Zwei-Agenten-Workflow kombiniert. OpenAIs Hermes ist jedoch etwas völlig anderes. Gleicher Name, anderes Unternehmen, andere Architektur. Kontext ist entscheidend.

OpenAIs Hermes – zumindest basierend auf den geleakten Frontend-Ressourcen und den in der ChatGPT-Web-App vorinstallierten Modulen – ist eine Plattform für persistente Agenten. Keine Einmal-Task-Runner. Nicht „Erledige diese Aufgabe und gib eine Rückmeldung zurück“. Agenten, die man einmal definiert und die dann fortbestehen: über Sitzungen hinweg, geplante Arbeiten erledigen, auf Auslöser reagieren, mit externen Tools verbunden bleiben und rückmelden, sobald etwas Relevantes geschieht.

Falls Ihnen das bekannt vorkommt: Das ist genau die architektonische Richtung, in die auch Anthropic mit seiner Oberfläche für Managed Agents gegangen ist, und es ist auch die Richtung, in die dutzende kleinere Unternehmen (einschließlich des eben genannten Hermes Agent von Nous Research) entwickeln. Persistente Agenten sind keine Idee eines einzelnen Anbieters. Sie sind der logische nächste Schritt im Konsens der Branche.

Der Unterschied bei OpenAI ist die Verbreitung. ChatGPT hat Hunderte Millionen Nutzer. Wenn persistente Agenten in dieses Produkt integriert werden — nicht als separate Entwickleroberfläche, sondern als Feature, das jeder Plus-Nutzer aktivieren kann — verändert sich das Standardverhalten von „mit einer KI chatten“ auf eine Weise, die später ganz selbstverständlich wirken wird, aber jetzt gerade radikal erscheint.

Was ich – basierend auf den geleakten Ressourcen und dem Muster aller bisherigen Plattformen für persistente Agenten – erwarte, wie Hermes beim Launch aussehen wird:

• Agentendefinitionen, die über Chats hinweg bestehen bleiben. Sie erstellen einen Agenten einmal – geben ihm eine Rolle („mein Rechercheassistent“), einen Satz an Fähigkeiten, eine Aufgabenliste, vielleicht ein paar Zugriffsgenehmigungen. Der Agent ist dann aus jedem Gespräch ansprechbar. Sie müssen ihn nicht jedes Mal neu einstellen.
• Geplante und ausgelöste Ausführungen. Der Agent arbeitet nach eigenem Zeitplan (z. B. jeden Morgen um 7 Uhr eine Zusammenfassung der aktuellen Nachrichten) oder reagiert auf Auslöser (wenn ein neuer Eintrag in meiner Notion-Datenbank erscheint, eine Antwort entwerfen). Das ist der Wandel vom Reaktiven zum Proaktiven.
• Dauerhafte Tool-Verbindungen. Agenten halten authentifizierte Verbindungen zu externen Diensten – Gmail, Kalender, GitHub, Slack, was auch immer das Berechtigungsmodell zulässt. Das Tool muss sich nicht bei jedem Durchlauf neu authentifizieren. Es ist bereits verbunden.
• Langfristiges Gedächtnis. Agenten erinnern sich an vorherige Ausführungen, vergangene Ergebnisse, erhaltenes Feedback. Wenn Sie dem Agenten letzte Woche gesagt haben, dass Sie Drei-Punkte-Zusammenfassungen statt Fließtext bevorzugen, sollte er sich das für immer merken – es sei denn, Sie setzen ihn explizit zurück.

Es gibt bislang kein Veröffentlichungsdatum. Das Feature befindet sich noch im internen Test und ist nur über die Begutachtung von Frontend-Ressourcen sichtbar. OpenAI steuert aber bereits öffentlich in diese Richtung – Workspace Agents wurden im April 2026 für Business-, Enterprise- und Edu-Pläne ausgerollt, und sie basieren weitgehend auf den architektonischen Überlegungen, auf denen auch Hermes aufbauen dürfte. Das Muster ist klar. Die Frage ist nur, wann – nicht ob.

Doch eines lässt mich immer wieder stutzen: Persistente Agenten funktionieren nicht ohne die beiden ersten Komponenten.

Persistente Agenten brauchen spezialisierte Fähigkeiten – ein Agent, der kontinuierlich in einem bestimmten Bereich wie juristische Recherche, Sicherheitsüberwachung oder Finanzanalyse läuft, benötigt ein Modell, das auf die jeweiligen Fachdaten trainiert wurde. Allgemeine Modelle versagen bei Spezialaufgaben auf Arten, die sich multiplizieren, wenn der Agent unbeaufsichtigt arbeitet. Das ist das Simula-Problem.

Persistente Agenten brauchen Beobachtbarkeit – ein Agent, der rund um die Uhr läuft, produziert um Größenordnungen mehr Log-Ausgaben als ein sitzungsbasierter Agent. Ohne ein Tool wie Euphan ist das Debuggen eines produktiven persistenten Agenten jedes Mal stundenlanges Log-Durchsuchen, sobald etwas schiefgeht. Das ist das Euphan-Problem.

Persistente Agenten brauchen eine Laufzeitumgebung – und genau das liefert Hermes selbst.

Man kann nicht einfach nur das dritte Teilstück ausliefern. Alle drei Komponenten müssen nahtlos ineinandergreifen, sonst bricht der gesamte Stack unter seiner eigenen Komplexität zusammen. Und damit komme ich zu dem Punkt, den ich Ihnen aus diesem Beitrag eigentlich mitgeben möchte.

Was diese Kombination für Entwickler wirklich bedeutet

Nehmen wir kurz Abstand. Was wir in Echtzeit beobachten, ist, dass die gesamte KI-Entwicklungspipeline vom Datenlayer aus neu aufgebaut wird.

Die Datenebene wird mit Systemen wie Simula neu definiert, bei denen synthetische Generierung mit logischer Herleitung und taxonomiegetriebener Auswahl ein Trainingsdatenfundament liefert, das besser ist als alles, was per Scraping gewonnen werden kann.

Die Observability-Ebene wird mit Log-Interpretationstools wie Euphan neu gestaltet, bei denen aus chaotischen Multi-Agent-Spuren verständliche Zeitachsen entstehen, die sich tatsächlich debuggen lassen.

Die Runtime-Ebene wird mit persistenten Agentenplattformen wie Hermes neu gedacht; hier hören Agenten auf, Einweg-Aufgaben zu sein, und werden zu langfristig agierenden Teamkollegen.

Jede dieser Ebenen ist für sich genommen bedeutend. Die Kombination aber ist entscheidend.

Wenn Sie 2026 etwas wirklich Relevantes auf Basis dieser Modelle bauen – ein SaaS-Produkt, ein internes Tool, eine Content-Pipeline, eine Automatisierung – ergibt sich daraus eine ganz praktische Konsequenz. Sie sollten nicht länger davon ausgehen, dass das Modell selbst der Engpass ist. Überprüfen Sie Ihre Annahmen anhand dieser drei Fragen:

1. Ist mein Anwendungsfall so spezialisiert, dass ein General-Purpose-Modell unterperformt? Falls ja, liegt die Lösung nicht im Wechsel zum neuesten Frontier-Modell. Die Lösung lautet entweder: auf ein spezialisiertes Modell warten, das auf Simula-artigen Daten trainiert wurde, oder selbst eines auf Basis synthetischer Generierung und eigener Taxonomie bauen.
2. Wenn mein Agent sich fehlerhaft verhält, wie lange brauche ich, um den Grund zu finden? Ist die Antwort „Stunden“ oder „Normalerweise starte ich einfach neu und hoffe“, dann brauchen Sie bessere Observability, nicht einen besseren Agenten. Setzen Sie jetzt, selbst wenn die Tools noch roh sind, auf Log-Interpretation – der Nutzen häuft sich exponentiell an.
3. Baue ich bei jeder Session den Zustand neu auf? Falls Sie Agenten immer noch als Einweg-Chat-Konversationen laufen lassen, befinden Sie sich auf dem absteigenden Ast. Fangen Sie frühzeitig an, für Persistenz zu entwerfen – auch schon vor dem Release von Hermes. Entkoppeln Sie den Zustand Ihres Agenten von der Chat-Oberfläche, speichern Sie ihn an einem langlebigen Ort, und die späteren Migrationskosten beim Wechsel auf eine persistente Agentenplattform werden nahezu null sein.

Nichts davon ist einfach. Ich selbst arbeite mich durch genau diese Fragen in meinem eigenen Stack – manches davon habe ich im Beitrag über das autonome Trainieren von AI-Agenten-Skills beschrieben – und dabei ziehen mich die Antworten konsequent in Richtung mehr Infrastruktur, weniger Magie: Mehr Taxonomie, mehr Logging, mehr Zustandsverwaltung. Weniger „wirf es ins Modell und schau, was passiert“.

Und letztlich, wenn ich so darüber nachdenke, ist das die Lektion, die jede ernstzunehmende Ingenieursdisziplin irgendwann lernt. Die Magie steckt in den langweiligen Teilen.

Real Talk: Wo ich denke, dass es scheitert

Ich will nicht den Eindruck hinterlassen, dass diese drei Tools die vollständige Antwort sind – denn das sind sie nicht. Hier sind die wesentlichen Einschränkungen und offenen Probleme, auf die ich hinweisen würde.

Simula funktioniert, weil die zugrunde liegenden Modelle stark genug sind. Sobald man versucht, dasselbe Pipeline-Konzept mit einem schwächeren Generator anzuwenden, verstärkt die Komplexitäts-Parametrisierung Fehler statt Qualität. Die meisten Teams haben keinen Zugang zu Gemini 2.5 Flash als Teacher Model. Wie Simula-äquivalente Pipelines mit einem engeren Budget aussehen sollen, ist noch ungelöst.

Euphan-artige Log-Interpretation ist nur so gut wie die zugrundeliegende Logstruktur. Wenn das Agenten-Framework, das du nutzt, schlampige, unstrukturierte Logs ausgibt – und viele tun das immer noch – kann keine Interpretationsschicht aus unsauberem Input Klarheit zaubern. Das Logformat selbst muss von Beginn an auf Observierbarkeit ausgelegt sein.

Persistente Agenten werfen eine Sicherheitsfrage auf, für die noch niemand eine wirklich gute Antwort hat. Ein Agent, der rund um die Uhr mit authentifizierten Verbindungen zu deinem Gmail, deinem GitHub, deinem Kalender läuft, bietet eine riesige Angriffsfläche. Wenn sich das Reasoning des Agenten manipulieren lässt – etwa durch Prompt Injection in einer eingehenden E-Mail oder ein vergiftetes Suchergebnis – betrifft der Schaden die gesamte authentifizierte Datenlandschaft. Jede mir bekannte Persistent-Agent-Plattform ist sich dessen bewusst, aber niemand hat es bisher vollständig gelöst. Genau deshalb wird Security-Tooling für KI-Agenten ein gewaltiger Bereich werden, und deshalb komme ich immer wieder darauf zurück.

Ehrlich gesagt sind diese drei Tools eher die Richtung als das Ziel. Die nächsten achtzehn Monate KI-Entwicklung werden damit verbracht werden, herauszufinden, wie dieser Stack tatsächlich Ende-zu-Ende in der Produktion funktioniert – für Anwendungsfälle, die nicht „Blogpost generieren“ oder „Dokument zusammenfassen“ heißen. Echte Arbeit. Echte Konsequenzen. Echte Anforderungen an Verfügbarkeit.

Und genau an solchen Problemen möchte ich arbeiten.

Was ich als Nächstes beobachte

Im nächsten Quartal verfolge ich drei ganz bestimmte Entwicklungen.

Erstens: Open-Source-Replikationen von Simula. Die Publikation ist ausreichend detailliert, sodass ein motiviertes Team die Pipeline außerhalb der Google-Infrastruktur nachbauen könnte. Ich rechne innerhalb von 60 Tagen mit der ersten ernstzunehmenden Open-Source-Implementierung, und wer sie überzeugend liefert, wird zum Standardwerkzeug für spezialisierte synthetische Datensätze in der Open-Source-Welt.

Zweitens: Standards für Log-Interpretation. Momentan hat jedes Agenten-Framework sein eigenes Logformat. OpenAI unterscheidet sich von Anthropic, unterscheidet sich von LangChain, unterscheidet sich wiederum von Nous Research. Diese Fragmentierung wird zwangsläufig zu einem gemeinsamen Trace-Standard führen — vermutlich auf Grundlage der OpenTelemetry-Konventionen — und das erste Framework mit echter Interoperabilität gewinnt enorm an Ansehen unter den Entwicklern.

Drittens: Das Release-Fenster von Hermes. Ich sehe eine Wahrscheinlichkeit von 60%, dass Hermes noch vor Ende Q3 2026 öffentlich verfügbar ist, basierend auf dem bereits fortgeschrittenen Frontend-Integrationsstand. Falls es erscheint, wandelt sich das „Always-On-Agent“-Muster von einem Nischenthema für Entwickler zum Standard für Hunderte Millionen ChatGPT-Nutzer innerhalb weniger Wochen. Das wäre ein ereignisprägender Wendepunkt.

Beobachten Sie alle drei Entwicklungen genau. Vermutlich wird eine davon die größte KI-Story des Sommers werden.

Die Studie, die ich eingangs erwähnt hatte — das Simula-Paper, das ich beinahe überblättert hätte — ist der Grund, warum ich inzwischen glaube: Die wichtigste KI-Arbeit 2026 findet nicht auf der Modell-Ebene statt. Sie findet im Daten-Design, in Observability und im Runtime-Bereich statt. Unspektakulär. Infrastruktur-geprägt. Mit enormen Auswirkungen.

Wenn Sie nur einen Satz aus diesem Abschnitt mitnehmen, dann lesen Sie diesen zweimal. Und werfen Sie dann einen Blick auf Ihren eigenen Stack: Welche der drei Schichten ist am schwächsten? Korrigieren Sie zuerst diese. Alles Weitere ergibt sich daraus.

Häufig gestellte Fragen

Was bedeutet synthetische Datenerzeugung im KI-Training?

Synthetische Datenerzeugung ist der Prozess, mithilfe von KI-Modellen Trainingsbeispiele zu erstellen, die im ursprünglichen Datensatz nicht vorhanden waren. Moderne Systeme wie Googles Simula nutzen reasoning-first-Taxonomien und eine duale Kritiker-Validierung, sodass die generierten Daten in spezialisierten Domänen reale Daten erreichen oder übertreffen können. Den vollständigen Mechanismus finden Sie im Simula-Abschnitt oben.

Warum sind synthetische Daten für spezialisierte KI-Domänen besser als reale Daten?

Reale Daten aus Bereichen wie Cybersecurity, Recht und Medizin sind oft durch Datenschutzgesetze geschützt, über proprietäre Quellen verteilt oder schlicht nicht in der nötigen Menge für Trainingszwecke verfügbar. Gut gestaltete synthetische Daten können die gesamte Taxonomie einer Domäne abdecken – einschließlich seltener Fälle – und das mit kontrollierter Qualität. In Googles Simula-Benchmarks erzielten mit synthetischen Daten trainierte Modelle bei spezialisierten Aufgaben teils bessere Ergebnisse als Modelle, die mit realen Daten trainiert wurden.

Was ist Mode Collapse bei synthetischen Daten und wie kann man es verhindern?

Mode Collapse tritt auf, wenn ein Generator-Modell repetitive, eng gefasste Beispiele produziert, die auf den ersten Blick vielfältig erscheinen, tatsächlich aber nur einen kleinen Ausschnitt der realen Verteilung abdecken. Simula verhindert dies durch die Abdeckung einer strukturierten Taxonomie und den Einsatz von Metaprompts – Prompts, die weitere Prompts generieren – um echte Variation in Blickwinkel, Format und Argumentationstiefe zu erzwingen.

Wann wird OpenAIs Hermes Persistent Agent Plattform veröffentlicht?

OpenAI hat noch kein Veröffentlichungsdatum für das Hermes Persistent Agent Feature bekanntgegeben. Frontend-Ressourcen und vorinstallierte Module, die in der ChatGPT-Webanwendung entdeckt wurden, weisen jedoch auf eine aktive Entwicklung hin. Verwandte Funktionen wie Workspace Agents wurden bereits im April 2026 für Business-, Enterprise- und Edu-Pläne veröffentlicht. Ein öffentlicher Hermes-Release im Laufe des Jahres 2026 erscheint auf Basis dieses Musters wahrscheinlich.

Was ist ein AI Agent Log Interpreter und warum brauchen Entwickler ihn?

Ein AI Agent Log Interpreter ist ein Werkzeug, das rohe, verschachtelte Agent-Logs – Tool-Aufrufe, Argumentationsverläufe, Wiederholungen, Statusübergänge – in lesbare, strukturierte Timelines übersetzt. OpenAIs Euphan-ähnliche Oberfläche und das Agents SDK Tracing Dashboard zeigen jeden Schritt, die ausführende Rolle, die verwendeten Tools und die Entscheidungsgründe an. Ohne diese Ebene bedeutet das Debugging eines fehlverhaltenen Agents oftmals, tausende Zeilen rohen JSON manuell durchsuchen zu müssen.

Lassen Sie uns zusammenarbeiten

Sie möchten KI-Systeme entwickeln, Workflows automatisieren oder Ihre technologische Infrastruktur skalieren? Ich unterstütze Sie gerne dabei.

• Fiverr (individuelle Lösungen & Integrationen): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (Enterprise-Lösungen): ramlit.com
• ColorPark (Design & Branding): colorpark.io
• xCyberSecurity (Sicherheitsdienste): xcybersecurity.io