De AI-datacrisis: Simula, Euphan en Hermes op de proef gesteld

De AI-datacrisis: Simula, Euphan en Hermes op de proef gesteld

Het paper dat mij vorige week alles deed laten vallen, ging niet over een nieuw frontier-model. Het was geen benchmark-lek. Het was niet eens een officiële aankondiging — het was een onderzoeksdrop van Google met een titel die zo droog was dat de meeste mensen er voorbij scrolden. "Orchestrating Synthetic Datasets with Reasoning." Ook ik was bijna doorgerold.

Toen las ik de zin die zich drie dagen in mijn hoofd nestelde: modellen getraind op de synthetische data presteerden soms beter dan modellen getraind op echte datasets. Niet gelijkwaardig. Beter. In gespecialiseerde domeinen — cybersecurity, juridisch redeneren, medisch — waar "echte" data óf achter privacywetgeving zit óf te duur is om te verzamelen, wist een team van Google een systeem te bouwen dat zelf tot trainingsdata redeneerde die beter was dan de realiteit.

Dat paper — waarmee het framework Simula werd geïntroduceerd — is de helft van wat ik in dit artikel wil ontleden. De andere helft is wat OpenAI in dezelfde periode ontwikkelde: een log-interpretatielaag die insiders steevast "Euphan" noemen, en een persistent-agent platform met de codenaam Hermes, dat stilletjes in ChatGPT’s vooringeladen frontendmodules wacht tot de releasevlag wordt omgezet.

Drie tools. Eén onderliggende verschuiving. En die verschuiving — waarvan ik betoog dat het het belangrijkste is dat er momenteel in AI gebeurt — is dat de bottleneck is verplaatst. Het draait niet langer om compute. Het draait zelfs niet meer om de modelgrootte. Het draait om de datapijplijn die het model voedt, de observatielaag die de agent volgt, en de runtime die de agent in leven houdt tussen sessies. Alle drie zijn stuk. Alle drie worden nu tegelijk gerepareerd door de twee labs die het meest te verliezen hebben als dat niet gebeurt.

Dit is wat ik vond toen ik in elk onderdeel dook — wat echt is, wat pure vaporware blijft, en wat deze combinatie betekent voor iedereen die in 2026 verder wil bouwen op deze modellen.

Waarom de Datacrisis Erger Is Dan Meeste Ontwikkelaars Beseffen

Het gangbare verhaal over de vooruitgang van AI is een verhaal van opschaling. Grotere modellen, meer parameters, meer rekenkracht, betere resultaten. Dat verhaal werkte tot ongeveer een jaar geleden. Toen veranderde er iets, en niemand in de consumentenpers had het echt door.

De teams die grensverleggende modellen trainen, zijn door de voorraad aan kwalitatief internetmateriaal heen. Niet qua hoeveelheid — er is nog steeds genoeg tekst op het internet. Maar de signaal-ruisverhouding van wat er nog te scrapen valt, is ingestort. De hoogwaardige tekst is opgebruikt in eerdere trainingsruns. Wat rest is gedupliceerd, machinaal gegenereerd, of te oppervlakkig om een model iets nieuws bij te brengen.

Voor algemene chatmodellen zoals GPT, Gemini en Claude uit zich dit in afnemende meeropbrengsten van schaalvergroting. Elke verdubbeling van het aantal trainingstokens levert een kleinere verbetering op dan de vorige. De curve begint af te vlakken.

Voor gespecialiseerde domeinen is het probleem structureel anders en veel ernstiger. Wil je een model trainen dat echt goed is in cybersecurity-redeneren, dan heb je data nodig die de daadwerkelijke taxonomie van aanvallen, dreigingsactoren, kwetsbaarheidsklassen en mitigatiestrategieën representeert. Die data bestaat — maar is gefragmenteerd over propriëtaire dreigingsinformatiefeeds, gesloten incidentrapportages, en de impliciete kennis van senior analisten die het nooit zullen opschrijven.

Juridisch redeneren? Afgeschermd door privilege, achter betaalmuren, of begraven in jurisdictiespecifieke jurisprudentie die nooit door één bron is samengevoegd.

Medisch? HIPAA bestaat met goede reden. De data waarop je zou willen trainen, is precies de data die je wettelijk niet op schaal mag gebruiken.

Ik heb dit persoonlijk ervaren. Wanneer ik heb geprobeerd mainstream modellen zorgvuldig te laten redeneren over beveiligingsproblemen in specifieke frameworks, leverden ze zelfverzekerde output die bij grondige controle uiteenvalt. Niet omdat de modellen slecht zijn — maar omdat de data waarop ze getraind zijn het echte werkveld niet dekt. Ze hebben de Wikipedia-versie van cybersecurity geleerd, niet de versie waarin een werkende pentester opereert.

Dit is de muur. En de weg om die muur heen — de aanpak waar elk serieuze AI-lab inmiddels twee jaar aan werkt — is synthetische data. Niet de versie synthetische data van 2023, die in wezen neerkwam op “vraag GPT-4 om meer trainingsvoorbeelden te schrijven en hoop op het beste.” Maar de versie van 2026, waar Simula voor staat.

Simula: Hoe redenering-gedreven datageneratie er daadwerkelijk uitziet

Ik geef eerlijk toe: toen ik het Simula-paper voor het eerst doorspitte, dacht ik dat het wéér een variant was op het bekende patroon “LLM genereert synthetische voorbeelden, dan filtert een LLM ze”. Dat patroon bestaat al sinds 2023 en heeft een bekend faalpunt — de generator vervalt in een nauwe verdeling van voorbeelden die divers lijken, maar in werkelijkheid slechts een smalle strook van de mogelijkheidruimte beslaan. De technische term is mode-collapse, en het is de reden dat de meeste synthetische datapijplijnen stiekem achterblijven bij echte data, ondanks het genereren van miljoenen voorbeelden.

Simula is dat niet. De architectuur is echt anders, en juist dat verschil levert de interessante prestatieverbeteringen op. Dit is het daadwerkelijke mechanisme, in volgorde van uitvoering binnen het framework.

Stap één: gestructureerde domeinmapping. Voor er iets gegenereerd wordt, bouwt Simula een hiërarchische taxonomie van het doeldomein. Voor cybersecurity omvat die taxonomie aanvalstypes (phishing, injectie, supply chain, social engineering, etc.), categorieën dreigingsactoren (natiestaat, georganiseerde misdaad, hacktivist, insider), soorten kwetsbaarheden (buffer overflow, logische fout, raceconditie, misconfiguratie), en mitigatiestrategieën. Iedere tak kent vertakkingen. De taxonomie is de kaart van wat goede dekking betekent.

Deze stap alleen al is gestructureerder dan de meeste synthetische datapijplijnen. De meeste pipelines gaan ervan uit dat het generatormodel vanzelf diverse voorbeelden oplevert. Dat zal niet gebeuren. Het model produceert voorbeelden met een bias naar wat oververtegenwoordigd was in zijn eigen trainingsdata.

Stap twee: gecontroleerd samplen. In plaats van de generator willekeurig onderwerpen te laten kiezen, sampled Simula doelgericht door de taxonomie heen. Als cybersecurity 400 nodes telt, zorgt de sampler dat elke node redelijk wordt vertegenwoordigd — inclusief de zeldzame, complexe gevallen die een random sampler slechts één op de tienduizend keer zou binnenhalen. Dit is het tegengif tegen mode-collapse: je kúnt niet instorten tot een nauwe distributie als de sampler je expliciet dwingt het hele spectrum te bestrijken.

Stap drie: metapromptgeneratie. Hier wordt Simula interessant. Het systeem genereert niet direct trainingsvoorbeelden, maar prompts die trainingsvoorbeelden opleveren. Die metaprompts bevatten beperkingen op formaat, moeilijkheidsgraad, invalshoek en diepte van redenering. De metapromptlaag introduceert variatie die een direct-generatiesysteem nooit kan evenaren, omdat de metaprompts zélf al divers zijn.

Denk aan het verschil. Directe generatie: “Schrijf een cybersecurity Q&A over SQL-injectie.” Je krijgt duizend variaties van in wezen hetzelfde antwoord. Metapromptgeneratie: “Schrijf twintig verschillende prompt-templates die elk een kwalitatief hoogwaardig trainingsvoorbeeld over SQL-injectie opleveren — één vanuit het perspectief van een incident-responder, één als code-review, één als compliance-audit, één als red-teamrapport, één als eerste kennismaking door een junior engineer, enzovoort.” Nu genereert het model uit ontwerp verschillende invalshoeken, niet per ongeluk.

Stap vier: complexiteitsparameterisatie. Simula behandelt complexiteit als een onafhankelijke as van diversiteit. Je kunt simpele voorbeelden genereren verdeeld over de volledige taxonomie, of complexe voorbeelden over dezelfde taxonomie, of een doelbewuste mix. Google-onderzoekers meldden dat het opvoeren van de complexiteitsparameter tot wel 10% prestatieboost opleverde op benchmarks voor redeneervraagstukken — mits de onderliggende generatormodel krachtig genoeg was. Zwakke generators met een te hoge complexiteit leverden op grote schaal ogenschijnlijk plausibele, maar feitelijk foute voorbeelden op, wat het studentmodel juist schaadde.

Dat is een cruciale kanttekening. Complexiteit is een vermenigvuldiger, geen oplossing. Het versterkt de kwaliteit van de generator — in beide richtingen.

Stap vijf: duale criticus kwaliteitscontrole. Elk gegenereerd voorbeeld passeert twee beoordelaars. De eerste vraagt: “Is dit correct?” De tweede vraagt, los daarvan: “Is dit incorrect?” De formulering is hier essentieel. Twee keer aan dezelfde criticus “is dit correct?” vragen, levert gecorreleerde antwoorden op. De tweede evaluatie als een tegenspraak formuleren, dwingt een onafhankelijke redeneerslag. Beide antwoorden worden gecombineerd tot een validatiescore. Voorbeelden die beide filters doorstaan, blijven over. Voorbeelden die de ene criticus correct en de andere incorrect acht, worden gemarkeerd voor review. Deze structuur met twee vragen vangt de plausibele-maar-onjuiste outputs die systemen met één criticus missen.

Het team testte deze pijplijn met Gemini 2.5 Flash als teachermodel en Gemma-3 4B als student; tot 512.000 datapunten per domein werden gegenereerd, geëvalueerd over vijf domeinen. Het hoofdresultaat — dat synthetische data echte data evenaarde of overtrof in gespecialiseerde domeinen — hield stand bij meerdere evaluaties.

De eerlijke kanttekening uit het paper, die niemand op Twitter citeerde: er is geen enkele optimale configuratie. De relatie tussen “goede” synthetische data en de prestaties van het eindmodel is volgens de onderzoekers diep idiosyncratisch. Verschillende domeinen vragen om verschillende complexiteitsmixen, taxonomiedieptes en criticusgewichten. Simula geeft je de knoppen, maar vertelt niet waar je ze op moet instellen.

Maar het punt is niet dat Simula een wondermiddel is. Het punt is dat het paradigma is verschoven. De vraag was “hoeveel data kun je verzamelen?” De vraag is nu “hoe goed kun je de data ontwerpen?” En de winnaars van de volgende golf specialistische AI zijn niet de labs met de meeste scrapers. Het zijn de labs met de beste taxonomen.

Euphan: Waarom OpenAI Stiekem een Log Viewer Bouwde

Laat me hier even pauzeren, want de tweede tool in dit verhaal heeft context nodig die de eerste niet had.

Als je nog nooit een agent-style AI-systeem hebt gebouwd, klinkt het concept van een "log" waarschijnlijk als iets dat je aantreft op een datacenterdashboard. Iets saais. Iets waar ops-mensen zich mee bezighouden. Laat me dat rechtzetten, want dat beeld klopt niet en kost builders daadwerkelijk tijd.

Een agent die een zelfs maar matig complexe taak uitvoert — bijvoorbeeld het onderzoeken van een onderwerp, het extraheren van gestructureerde data, het schrijven van een concept, en het ergens posten — genereert een log die totaal niet lijkt op een traditionele serverlog. Het is een geneste boom van tool-calls, modelresponses, redeneertraces, tussentijdse outputs, pogingen tot herhaling, toestemmingsverleningen, en staatsovergangen. Eén enkele agent-run kan duizenden regels JSON opleveren. Het grootste deel daarvan is ruis. Slechts een klein percentage is het eigenlijke verhaal van wat de agent deed en waarom.

Wanneer zo'n agent zich misdraagt — en ze misdragen zich allemaal vroeg of laat — is het aan jou als ontwikkelaar om het punt in die log te vinden waar het redeneren misging. In een goed gestructureerde log is dat nog steeds tijdrovend. In een ruwe JSON dump kost het je uren scrollen. Ik heb avonden gespendeerd aan het grep-en door agent-logs om te achterhalen waarom een tool-call die had moeten vuren het niet deed, of waarom een model een parameter hallucineerde die helemaal niet in de prompt stond.

Dit is het probleemgebied waar OpenAI stilletjes op inspeelt. De interne naam die rondgaat is Euphan, al heeft het bedrijf publiekelijk het merendeel van die functionaliteit nu in de Agents SDK tracing dashboard en het nieuwe workspace-agents oppervlakte in ChatGPT verwerkt. Hoe je het onderliggende systeem ook noemt, de taak is specifiek en belangrijk: het neemt ruwe agent-logs en maakt er iets van dat een mens snel kan lezen.

Hoe dat er concreet uitziet:

• Schoon gestructureerde tijdlijnen. In plaats van geneste JSON krijg je een lineaire reeks stappen, elk met een duidelijke rollabel (planner, retriever, tool caller, responder), een timestamp, en een eenregelige samenvatting. Klik op een stap voor volledige details. Scan snel de tijdlijn om het kantelpunt te vinden.
• Inspectie van rollen en tools. Elke tool-call toont welke agent hem aanriep, welke parameters werden meegegeven, wat er terugkwam, en hoeveel tijd het kostte. Als een tool een 429 rate-limit fout teruggeeft veertig minuten na de start, toont de tijdlijn dit zonder dat je hoeft te zoeken.
• Zichtbaarheid van redeneerbeslissingen. Moderne agents geven redeneertraces af: de interne motivatie van het model om een bepaalde actie boven een ander te kiezen. Een leesbaar log-oppervlak toont die traces als inline annotaties op de tijdlijn, zodat je niet alleen ziet wat de agent deed, maar ook waarom die het als de juiste keuze beschouwde.
• Direct log bewerken. Dit was de functie die mij het meest verraste. Je kunt een log-entry bewerken, de aangepaste status opslaan, en de run vanaf dat punt herstarten. Het is als git rebase voor agent-geschiedenis. Ik heb dit elders nog nergens schoon zien werken.
• Filteren, zoeken en metadata-queries. Wanneer je runs hebt die uren duren en duizenden stappen omvatten is grep niet voldoende. Je hebt gestructureerde queries nodig. "Toon me alle tool-calls met status != 200." "Toon me redeneertraces waar confidence onder 0.6 zakte." Die laag is aanwezig.

De reden dat ik telkens weer naar deze tool terugkeer, ook al is het minder glamoureus dan een nieuw frontier model, is dat het een echt probleem oplost waar ik wekelijks tegenaan loop. Toen ik een persoonlijke agent stack bouwde met de Anthropic Agent SDK, was het moeilijkste gedeelte niet het schrijven van de agent. Het was het debuggen van de agent wanneer deze zich misdroeg. Uiteindelijk bouwde ik een huisgemaakte log viewer in een Notion-database omdat ik het zat was om ruwe JSON te lezen. Als ik destijds iets als Euphan had gehad — of een soortgelijk oppervlak voor Anthropic-logs — had ik een week eerder kunnen shippen.

Dit is developer-infrastructuur. Het is geen feature voor consumenten. Het zal niet op een keynote verschijnen. Maar de teams die production agents shippen zullen terugkijken op log-interpretatietools als het moment dat de hele workflow beheersbaar werd.

Nu, het derde onderdeel.

Hermes: De Verschui­ving van Chatbot naar Altijd-Aan Teamgenoot

Hermes is de codenaam die de afgelopen weken is uitgelekt uit interne builds bij OpenAI, en ik ben hier voorzichtig omdat er naamverwarring is op de markt. De open-source gemeenschap heeft namelijk al een tool genaamd Hermes Agent van Nous Research — ik heb geschreven over het combineren ervan met OpenClaw in een twee-agenten workflow. OpenAI’s Hermes is echter iets totaal anders. Zelfde naam, ander bedrijf, andere architectuur. Context is belangrijk.

OpenAI’s Hermes — althans op basis van de uitgelekte frontend-bestanden en de voorgeïnstalleerde modules in de ChatGPT webapp — is een platform voor persistente agenten. Geen eenmalige taakuitvoerders. Niet “voer deze taak uit en geef het resultaat terug.” Agenten die je één keer definieert en die blijven bestaan over meerdere sessies heen, geplande taken uitvoeren, reageren op triggers, verbonden blijven met externe tools en terugrapporteren als er iets relevants gebeurt.

Als dit bekend klinkt, is dat omdat het dezelfde architectuur is als die van Anthropic, met hun surface voor beheerde agenten, en dezelfde richting waarin een dozijn kleinere bedrijven (waaronder de Hermes Agent van Nous Research die ik net noemde) zich ontwikkelen. Persistente agenten zijn geen idee van één leverancier. Ze zijn de breed gedragen volgende stap.

Wat anders is aan de aanpak van OpenAI, is de distributie. ChatGPT heeft honderden miljoenen gebruikers. Wanneer persistente agenten in dat product verschijnen — niet als aparte ontwikkelaarsfunctie, maar als optie die iedere Plus-gebruiker kan inschakelen — verandert het standaardgedrag van “chatten met een AI” op een manier die achteraf vanzelfsprekend zal lijken, maar nu radicaal aanvoelt.

Hoe ik verwacht dat Hermes eruit zal zien bij lancering, gebaseerd op de gelekte informatie en het patroon dat alle andere persistente-agentenplatforms volgen:

• Agent-definities die blijven bestaan over verschillende chats heen. Je maakt een agent aan — geeft het een rol (“mijn onderzoeksassistent”), een reeks vaardigheden, een takenlijst, eventueel wat toegangsrechten. De agent wordt aanspreekbaar vanuit elk gesprek. Je hoeft het niet iedere keer opnieuw te instellen.
• Geplande en getriggerde uitvoering. De agent werkt volgens een eigen schema (elke ochtend om 7 uur, vat het nieuws van de nacht samen) of op triggers (wanneer er een nieuwe notitie in mijn Notion-database verschijnt, stel een antwoord voor). Dit is de verschuiving van reactief naar proactief.
• Blijvende tool-koppelingen. Agenten onderhouden geauthentiseerde verbindingen met externe diensten — Gmail, Calendar, GitHub, Slack, wat het toegangsmodel ook toestaat. De tool hoeft zich niet telkens opnieuw te authenticeren. De verbinding staat al klaar.
• Langdurig geheugen. Agenten onthouden eerdere runs, eerdere uitkomsten, eerdere feedback. Als je de agent vorige week vertelde dat je liever drie bullets hebt dan een alinea-samenvatting, zal de agent dit onthouden totdat jij dit expliciet reset.

Er is nog geen releasedatum. De functie wordt nog intern getest en is alleen zichtbaar via inspectie van de frontend-bronnen. Dat gezegd hebbende, OpenAI beweegt hier publiekelijk naartoe: workspace agenten kwamen in april 2026 beschikbaar voor de Business-, Enterprise- en Edu-abonnementen, gebaseerd op architecturale principes waarop Hermes eveneens zou bouwen. Het patroon is duidelijk. De vraag is wanneer, niet of.

Maar ik blijf telkens bij het volgende punt terugkomen: persistente agenten werken niet zonder de eerste twee componenten.

Persistente agenten vereisen gespecialiseerde capaciteiten — een agent die continu draait binnen een specifiek domein (juridisch onderzoek, beveiligingsmonitoring, financiële analyse) heeft een model nodig dat getraind is op data uit dat domein. Generalistische modellen falen op specialistische taken, en die fouten stapelen zich exponentieel op als de agent onbemand draait. Dat is het Simula-probleem.

Persistente agenten vereisen observability — een agent die 24/7 draait, genereert orders van grootte meer logdata dan een sessiegerichte agent. Zonder een tool als Euphan betekent het debuggen van een persistente agent urenlang door logs spitten elke keer dat er iets misgaat. Dat is het Euphan-probleem.

Persistente agenten vereisen een runtime — en dát is precies wat Hermes biedt.

Je kunt niet alleen het derde stuk leveren. Alle drie de componenten moeten samenwerken, anders stort de hele stack onder zijn eigen gewicht in elkaar. Dat is wat ik je echt wil meegeven uit deze post.

Wat Deze Combinatie Echt Betekent Voor Builders

Zoom even uit. Wat we op dit moment in real time zien, is dat de volledige AI-ontwikkelketen opnieuw wordt opgebouwd, vanaf de datalaag naar boven toe.

De datalaag wordt opnieuw opgebouwd met systemen als Simula, waar synthetische generatie met redeneervermogen en taxonomie-gedreven sampling trainingsdata oplevert die beter is dan alles wat je kunt scrapen.

De observeerbaarheidslaag wordt opnieuw opgebouwd met log-interpretatietools als Euphan, waar rommelige multi-agent traces worden omgezet in leesbare tijdlijnen die je daadwerkelijk kunt debuggen.

De runtime-laag wordt opnieuw opgebouwd met persistent-agent platforms als Hermes, waar agents geen eenmalige taken meer zijn, maar langdurige teamgenoten worden.

Elk van deze onderdelen is individueel van betekenis. Maar juist de combinatie is waar het om draait.

Als je in 2026 iets serieus bouwt bovenop deze modellen — een SaaS-product, een interne tool, een contentpipeline, een automatisering — dan volgt hieruit een praktische consequentie. Je moet stoppen met aannemen dat het model de bottleneck is. Toets je aannames aan deze drie vragen:

1. Is mijn use case zo gespecialiseerd dat een generalistisch model ondermaats presteert? Zo ja, dan is de oplossing niet het nieuwste frontier-model kiezen. De oplossing is óf wachten op een gespecialiseerd model getraind op Simula-achtige data, óf er zelf een bouwen via synthetische generatie op je eigen taxonomie.
2. Hoe lang duurt het voordat ik begrijp waarom mijn agent zich misdraagt? Als het antwoord "uren" is of "ik herstart meestal gewoon en hoop op het beste," dan heb je betere observability nodig, niet een betere agent. Begin nu alvast met het adopteren van log-interpretatietools, ook als het nog ruw is, want het resultaat groeit exponentieel.
3. Herbouw ik state bij elke sessie? Als je agents nog draait als eenmalige chatgesprekken, zit je aan de verliezende kant van de curve. Begin nu alvast te ontwerpen voor persistentie, zelfs nog voordat Hermes verschijnt: koppel de state van je agent los van het chatsurface, sla het ergens duurzaam op, en je migratiekosten zijn vrijwel nul zodra de persistent-agent platforms uitkomen.

Geen van dit alles is eenvoudig. Ik ben zelf door precies deze vragen gegaan in mijn eigen stack — sommige daarvan beschreef ik in de train AI agents skills autonomously post — en de antwoorden trekken me steeds meer richting infrastructuur in plaats van magie. Meer taxonomie, meer logging, meer statemanagement. Minder "gooi het naar het model en kijk wat er gebeurt."

Wat, nu ik erover nadenk, dezelfde les is die elke serieuze ingenieursdiscipline uiteindelijk leert. De magie zit in de saaie onderdelen.

Eerlijk Gesproken: Waar Dit Volgens Mij Fout Gaat

Ik wil je niet de indruk geven dat deze drie tools de volledige oplossing zijn, want dat zijn ze niet. Dit zijn wat mij betreft de echte beperkingen en openstaande problemen.

Simula werkt omdat de onderliggende modellen krachtig genoeg zijn. Zodra je probeert dezelfde pipeline toe te passen met een zwakkere generator, vergroot parameterisatie van complexiteit de fouten in plaats van de kwaliteit. De meeste teams hebben geen toegang tot Gemini 2.5 Flash als hun teachermodel. Hoe Simula-achtige pipelines eruitzien met een krapper budget is nog steeds onopgelost.

Interpretatie van logs à la Euphan is slechts zo goed als de onderliggende logstructuur. Als het agent-framework dat je gebruikt slordige, ongestructureerde logs genereert — en dat doen er nog steeds veel — kan geen enkele interpretatielaag helderheid scheppen uit rommelige input. Het logformaat zelf moet vanaf het begin ontworpen zijn voor observability.

Persistente agents vormen een veiligheidsvraagstuk waar nog niemand een overtuigend antwoord op heeft. Een agent die 24/7 draait met geauthenticeerde verbindingen met je Gmail, je GitHub, je agenda, vormt een groot aanvalsoppervlak. Als de redenering van de agent gemanipuleerd kan worden — via prompt-injectie in een binnenkomende e-mail, of een vergiftigd zoekresultaat — is de impact het volledige geauthenticeerde netwerk. Elk persistent-agentplatform dat ik heb gezien is zich hiervan bewust, maar geen enkele heeft dit volledig opgelost. Daarom wordt security tooling voor AI-agents een gigantische categorie, en daarom blijf ik erop terugkomen.

De eerlijke samenvatting is dat deze drie tools de richting aangeven, niet het eindpunt. De komende achttien maanden AI-bouw zullen worden besteed aan het uitzoeken hoe deze stack daadwerkelijk end-to-end in productie kan werken, voor use-cases die verder gaan dan “genereer een blogpost” of “vat een document samen.” Echt werk. Echte consequenties. Echte uptime-eisen.

En dat is precies het soort probleem waar ik aan wil werken.

Waar ik de komende tijd op let

Drie specifieke zaken houd ik het komende kwartaal in de gaten.

Ten eerste, open-source replicaties van Simula. Het paper is gedetailleerd genoeg dat een gemotiveerd team de pijplijn buiten de infrastructuur van Google zou kunnen herbouwen. Ik verwacht de eerste serieuze open-source-implementatie binnen 60 dagen, en wie dat voor elkaar krijgt, wordt meteen het standaardgereedschap voor synthetische data in gespecialiseerde domeinen binnen de open-sourcewereld.

Ten tweede, log-interpretatiestandaarden. Op dit moment heeft elk agentframework zijn eigen logformaat. OpenAI’s is anders dan die van Anthropic, die weer anders is dan LangChain’s, die weer verschilt van die van Nous Research. Die fragmentatie zal onvermijdelijk leiden tot een gemeenschappelijke traceerstandaard — waarschijnlijk gebaseerd op OpenTelemetry-conventies — en het eerste framework dat fatsoenlijke interoperabiliteit levert, wint veel ontwikkelaarssympathie.

Ten derde, de releasewindow van Hermes. Ik schat de kans op 60% dat deze publiekelijk uitgebracht wordt vóór het einde van Q3 2026, gebaseerd op de al vergevorderde frontend-integratie. Mocht het zover komen, dan wordt het “altijd-aan-agent”-patroon in een paar weken tijd van een niche voor ontwikkelaars de standaard voor honderden miljoenen ChatGPT-gebruikers. Dat is een gebeurtenis die een nieuwe categorie kan definiëren.

Let op alle drie. Waarschijnlijk wordt een ervan hét AI-verhaal van de zomer.

Dat paper dat ik aan het begin noemde — het Simula-paper waar ik bijna aan voorbij scrolde — is de reden dat ik nu geloof dat het belangrijkste AI-werk in 2026 niet op modellagen gebeurt. Het vindt plaats in datadesign, observeerbaarheid en runtime. Saai. Lijkt op infrastructuur. Maar van gigantisch belang.

Als je maar één ding uit deze post onthoudt, lees die zin dan twee keer. Kijk daarna naar je eigen stack en bepaal welke van de drie lagen het zwakst is. Pak die als eerste aan. De rest volgt vanzelf.

Veelgestelde Vragen

Wat is synthetische datageneratie bij AI-training?

Synthetische datageneratie is het proces waarbij AI-modellen trainingsvoorbeelden produceren die niet in de originele dataset voorkwamen. Moderne systemen zoals Google's Simula gebruiken reasoning-first taxonomieën en dual-critic validatie, zodat de gegenereerde data kan evenaren of zelfs beter kan zijn dan echte data in gespecialiseerde domeinen. Voor het volledige mechanisme, zie de Simula-sectie hierboven.

Waarom is synthetische data beter dan echte data voor gespecialiseerde AI-domeinen?

Echte data in domeinen als cybersecurity, juridisch en medisch is vaak afgeschermd door privacywetgeving, gefragmenteerd over propriëtaire bronnen, of bestaat simpelweg niet in de benodigde volumes voor training. Goed ontworpen synthetische data kan de volledige taxonomie van een domein dekken — inclusief zeldzame gevallen — met gecontroleerde kwaliteit. In benchmarks van Google's Simula presteerden modellen die getraind zijn op synthetische data soms beter dan modellen die zijn getraind op echte data voor gespecialiseerde taken.

Wat is mode collapse bij synthetische data en hoe voorkom je het?

Mode collapse treedt op wanneer een generatormodel herhalende, eenzijdige voorbeelden produceert, die oppervlakkig divers lijken maar slechts een smal deel van de echte distributie dekken. Simula voorkomt dit door te sampelen over een gestructureerde taxonomie en door gebruik van metaprompts — prompts die prompts genereren — waarmee daadwerkelijke variatie wordt afgedwongen in invalshoek, formaat en diepgang van redenering.

Wanneer wordt OpenAI's Hermes persistent agent platform uitgebracht?

OpenAI heeft nog geen releasedatum aangekondigd voor de Hermes persistent agent-functie. Frontend-resources en preloaded modules, die zijn ontdekt in de ChatGPT webapp, wijzen op actieve ontwikkeling; verwante functies zoals workspace agents zijn al in april 2026 uitgerold voor Business-, Enterprise- en Edu-abonnementen. Een publieke Hermes-release in 2026 lijkt waarschijnlijk op basis van dit patroon.

Wat is een AI agent log interpreter en waarom hebben ontwikkelaars die nodig?

Een AI agent log interpreter is een tool die rauwe, geneste agentlogs — tool calls, reasoning traces, retries, state transitions — omzet in leesbare gestructureerde tijdlijnen. OpenAI's Euphan-achtige interface en het Agents SDK tracing dashboard tonen iedere stap, de rol die hem uitvoerde, de gebruikte tools en de achterliggende redenatie. Zonder deze laag betekent het debuggen van een slecht functionerende agent dat je duizenden regels onbewerkte JSON moet doorzoeken.

Laten We Samenwerken

Wil je AI-systemen bouwen, workflows automatiseren of je technologische infrastructuur opschalen? Ik help je graag.

• Fiverr (maatwerk builds & integraties): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (oplossingen voor ondernemingen): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (beveiligingsdiensten): xcybersecurity.io