Van agentervaring naar institutioneel leervermogen: waarom WikiSkill een blauwdruk is voor zelfevoluerende AI-agents - en een nieuw beveiligingsrisico

Een AI-agent leert niet werkelijk doordat hij steeds meer uitvoerlogs bewaart. Leren ontstaat pas wanneer een systeem onderscheid maakt tussen wat er gebeurde, wat daarvan aannemelijk geleerd kan worden, en welk gedrag vervolgens daadwerkelijk uitgevoerd mag worden.

Dat onderscheid vormt de kern van WikiSkill (Tang et al., Google Research + Virginia Tech, arXiv v1, 27 augustus 2026). De auteurs introduceren een architectuur waarin ruwe agentervaringen niet rechtstreeks worden vertaald naar nieuwe instructies. Tussen ervaring en uitvoering wordt een persistente kennislaag geplaatst, een wiki waarin patronen, mislukkingen, eerdere interventies en succesvolle strategieën over meerdere optimalisatiecycli worden geconsolideerd.

De centrale bijdrage is daarom niet een nieuw taalmodel, trainingsalgoritme of geheugenmechanisme. WikiSkill is vooral een leer-control-plane voor agents. Het systeem organiseert een keten van ervaring naar kennis, van kennis naar procedure, en van procedure naar gecontroleerde activering.

De resultaten zijn substantieel. WikiSkill behaalt gemiddeld de beste prestaties voor vijf modellen en vijf uiteenlopende benchmarks. Tegelijkertijd laat de paper zien dat skills niet universeel overdraagbaar zijn. Een skill die het ene model sterk verbetert, kan de prestaties van een ander model juist volledig ondermijnen. De paper biedt daarmee zowel een blauwdruk voor cumulatief agentleren als bewijs dat skills een nieuwe software supply chain vormen die expliciete assurance nodig heeft.

Bestuurlijk oordeel

Mijn beoordeling van de paper:

Dimensie	Oordeel
Architecturale originaliteit	Hoog
Empirische breedte	Hoog
Causale bewijskracht van de wiki	Middelmatig tot hoog
Statistische robuustheid	Middelmatig
Reproduceerbaarheid	Middelmatig
Security-by-design	Laag
Productierijpheid	Laag
Strategische relevantie	Zeer hoog

De juiste conclusie is niet dat organisaties WikiSkill direct moeten implementeren. De juiste conclusie is: adopteer het architectuurprincipe, maar niet de experimentele implementatie zonder een aanvullende assurance-, security- en governancelaag.

Voor een omgeving zoals het Djimit-ecosysteem zou mijn besluit zijn:

• RESEARCH_VERDICT = STRONG_POSITIVE
• ARCHITECTURE_VERDICT = ADOPT_PATTERN
• CONTROLLED_CANARY = GO
• AUTONOMOUS_PRODUCTION_DEPLOYMENT = HOLD

1. Het fundamentele probleem: agentervaring verdampt

Agentframeworks genereren grote hoeveelheden ervaring: prompts en antwoorden, toolaanroepen, zoekresultaten, fouten, herstelpogingen, geslaagde strategieën, geweigerde of mislukte skillwijzigingen. In veel bestaande systemen blijven deze inzichten verspreid over afzonderlijke traces, reflecties, samenvattingen en wijzigingshistorie. Een volgende optimalisatie-iteratie analyseert opnieuw een deel van die informatie, maar bouwt niet noodzakelijk voort op een samenhangend kennisbeeld.

Bestaande methoden zoals EvoSkill, Trace2Skill en SkillOpt analyseren agenttraces en vertalen deze naar skillwijzigingen. EvoSkill bewaart bijvoorbeeld eerdere voorstellen en evaluatie-uitkomsten, terwijl Trace2Skill lokale lessen uit trajecten consolideert en SkillOpt reflecties en afgewezen wijzigingen gebruikt. Volgens de auteurs onderhouden deze methoden echter geen afzonderlijke, evoluerende representatie van wat het systeem inmiddels heeft geleerd.

WikiSkill introduceert daarom drie verschillende epistemische objecten:

• Ervaring: wat feitelijk tijdens een uitvoering gebeurde.
• Kennis: welke patronen en verklaringen uit meerdere ervaringen kunnen worden afgeleid.
• Vaardigheden: welke concrete instructies tijdens toekomstige taken moeten worden uitgevoerd.

Dit lijkt een eenvoudige scheiding, maar architecturaal is zij essentieel. Een uitvoeringslog is namelijk geen kennis. Een correlatie is geen betrouwbare regel. Een terugkerende fout is nog geen bewezen oorzaak. En een aannemelijke oplossing is nog geen productieklare skill. WikiSkill maakt deze transformaties expliciet.

2. De drie lagen van WikiSkill

De agentworkspace bestaat uit een Raw Layer, een Wiki Layer en een Skills Layer.

Laag	Functie	Belangrijkste artefacten	Enterprise-analogie	Primair risico
Raw Layer	Bewaren van uitvoeringshistorie	traces, observaties, toolacties, antwoorden	Event store, evidence lake	Geheimen, persoonsgegevens, promptinjectie
Wiki Layer	Consolideren van patronen en interventies	index.md, patroonpagina's, logs.md, skill-impact.md	Kennisgraph, claim ledger, ADR-register	Verouderde of vergiftigde kennis
Skills Layer	Uitvoerbare procedures	SKILL.md, PURPOSE.md	Code artifact, policy package	Misbruik van tools en bevoegdheden

De Raw Layer bevat onveranderlijke uitvoeringstrajecten. De Wiki Layer consolideert succesvolle strategieën, terugkerende fouten, eerdere skillvoorstellen en hun effecten. De Skills Layer bevat alleen de procedures die de inference-agent daadwerkelijk mag toepassen.

Elke skill bevat naast SKILL.md een PURPOSE.md. Daarmee wordt een relatie gelegd tussen een uitvoerbare procedure en de kennispatronen die haar creatie of wijziging motiveerden. Dat is een vroege vorm van provenance en decision traceability.

2.1 WikiSkill als compiler

Een nuttig mentaal model is dat WikiSkill geen gewoon geheugensysteem is, maar een compilerpipeline:

Uitvoeringstrajecten
        ↓
Ruwe bewijsobjecten
        ↓
Patroonextractie en consolidatie
        ↓
Epistemische tussenrepresentatie
        ↓
Procedurele skill
        ↓
Validatie en activering

In deze analogie zijn de raw traces de brondata, de wiki de intermediate representation, de skills de uitvoerbare artefacten, de validatieset de testomgeving, en de gatingfunctie de CI/CD-pipeline. De belangrijkste innovatie is de intermediate representation. In plaats van traces rechtstreeks te compileren naar gedrag, bouwt het systeem eerst een persistente hypothese- en patroonlaag op. Daarmee wordt agentleren minder vergelijkbaar met promptoptimalisatie en meer vergelijkbaar met gecontroleerde softwareontwikkeling.

3. De evolutionaire regelkring

De toestand van WikiSkill wordt op iteratie k weergegeven als:

Z_k = (S_k, W_k)

waarbij S_k de actieve skillset is en W_k de persistente wiki. Het systeem start zonder skills en zonder wiki:

(S_0, W_0) = (∅, ∅)

Iedere iteratie bestaat uit vier stappen.

Stap 1, inference. De inference-agent voert de trainingstaken uit met de huidige skills: τ_i ~ π(x_i; S_{k-1}). De agent krijgt de volledige actieve skillinhoud in zijn systeemprompt. De wiki is tijdens deze uitvoeringen niet toegankelijk. Hiermee proberen de auteurs skillretrieval en skilltriggering als experimentele verstorende variabelen uit te sluiten.

Stap 2, wiki-onderhoud. De Wiki Maintainer analyseert een selectie van succesvolle en mislukte traces: W'_k = M_WM(W_{k-1}, T_sample,k). Per iteratie worden maximaal acht traces geselecteerd, maximaal vijf mislukkingen en maximaal drie successen. Iedere trace wordt begrensd op 15.000 tekens. De maintainer kan nieuwe patronen toevoegen, bestaande patronen wijzigen, de index actualiseren en een evolutielog bijwerken.

Stap 3, skillvoorstel. De Skill Proposer krijgt toegang tot de wiki-index, de impacthistorie van eerdere skills, een overzicht van geslaagde en mislukte taken, geselecteerde raw traces en de huidige skillset. De proposer werkt als een ReAct-agent en moet ten minste vier uitvoeringstrajecten lezen voordat hij een wijziging voorstelt. Iedere iteratie produceert maximaal één atomaire wijziging, een nieuwe skill of een patch op een bestaande skill.

Stap 4, validatie en rollback. De kandidaat-skill wordt op de validatieset getest. Alleen een strikte verbetering wordt geaccepteerd: S_k = S'_k als R_val(S'_k) groter is dan R_best, anders S_k = S_{k-1}. Bij een afwijzing wordt de skillwijziging teruggedraaid. De wiki wordt echter nooit teruggedraaid. Het voorstel, de diff, de validatiescore en de acceptatie- of afwijzingsbeslissing worden aan skill-impact.md toegevoegd.

De epistemische asymmetrie

Dit creëert een interessante asymmetrie:

• Uitvoerbaar gedrag is reversibel
• Historische kennis is cumulatief
• Afgewezen interventies blijven beschikbaar

Dat is tegelijk de grootste kracht en de grootste kwetsbaarheid van WikiSkill. Een mislukte skillwijziging verdwijnt niet uit het leerproces. Zij wordt negatieve kennis. Een volgende proposer kan hierdoor voorkomen dat dezelfde fout opnieuw wordt gemaakt. Maar het systeem veronderstelt impliciet dat de wiki een betrouwbare representatie van eerdere ervaringen blijft. Wanneer een verkeerd patroon, een foutieve causaliteitsclaim of kwaadaardige instructie in de wiki terechtkomt, blijft ook die informatie persistent beschikbaar.

4. Negatieve kennis als leervermogen

De ALFWorld-case in de paper laat dit mechanisme goed zien. Tijdens de eerste iteratie constateert de Wiki Maintainer dat de agent in een herhalende lus terechtkomt. Een eerste voorgestelde skill blijkt de validatiescore niet te verbeteren en wordt afgewezen. De wijziging en afwijzing blijven echter opgeslagen. In de volgende iteratie stelt de proposer een specifiekere regel voor die voorkomt dat een object steeds naar zijn oorspronkelijke locatie wordt teruggebracht. Die wijziging wordt wel geaccepteerd. In een latere iteratie wordt de skill verder aangescherpt zodat iedere bewerkingssoort slechts eenmaal per object wordt toegepast.

Dit illustreert een belangrijk verschil tussen foutregistratie en leren:

• Foutregistratie: "De vorige aanpak werkte niet."
• Cumulatief leren: "De vorige aanpak werkte niet, onder deze omstandigheden, om deze vermoedelijke reden, en moet daarom niet opnieuw in dezelfde vorm worden voorgesteld."

WikiSkill bouwt dus niet alleen een bibliotheek van successen op. Het bouwt ook een bibliotheek van verworpen interventies op. In wetenschappelijke termen fungeert skill-impact.md als een rudimentair falsificatiegeheugen. Het voorkomt dat alleen positieve voorbeelden worden bewaard en vermindert daarmee een vorm van survivorship bias in agentoptimalisatie.

5. Experimentele opzet

De auteurs testen WikiSkill op vijf benchmarks:

Benchmark	Taaktype	Train	Validatie	Test	Tools
LiveMath	Wiskundig redeneren	35	18	124	Geen
SealQA	Websearch en fact retrieval	16	10	85	Search, file read
SpreadsheetBench	Spreadsheetmanipulatie	80	40	280	Bash en Python
OfficeQA	Long-context documentonderzoek	50	24	172	Glob, grep, read
ALFWorld	Sequentiële omgevingstaken	39	18	134	Simulatieacties

De modellen zijn Qwen-3.5-4B, Qwen-3.5-9B, Qwen-3.6-27B, Gemma-4-31B en Gemini-3.5-Flash. WikiSkill wordt vergeleken met Trace2Skill, EvoSkill, SkillOpt en een baseline zonder skills. Alle skillmethoden beginnen met een lege skillset. Iedere volledige evolutionaire run wordt driemaal onafhankelijk uitgevoerd. De testresultaten worden gemiddeld en met 1.000 paired bootstrap-resamples geëvalueerd.

Deze opzet is breed voor een eerste paper. Zij omvat gesloten en open-weight modellen, single-step en multi-step taken, toolvrije en toolgebruikende agents, en reasoning, retrieval, codegeneratie en omgevingsinteractie. Dat maakt de resultaten inhoudelijk relevanter dan een demonstratie op één benchmark of één model.

6. De hoofdresultaten

De gemiddelde prestaties over de vijf benchmarks:

Model	Zonder skill	WikiSkill	Winst (pp)	Beste concurrent	Voorsprong WikiSkill
Qwen-3.5-4B	26,2	38,5	+12,3	35,2	+3,3
Qwen-3.5-9B	29,9	47,4	+17,5	42,3	+5,1
Qwen-3.6-27B	39,4	63,3	+23,9	53,3	+10,0
Gemma-4-31B	41,3	54,9	+13,6	49,1	+5,8
Gemini-3.5-Flash	49,5	68,1	+18,6	56,1	+12,0

Op basis van een eigen telling van de 25 afzonderlijke model-benchmarkcombinaties verbetert WikiSkill de baseline zonder skills in 23 gevallen. Eén combinatie blijft gelijk en één combinatie verslechtert. Numeriek presteert WikiSkill in 19 van de 25 cellen beter dan de sterkste concurrerende skillmethode, in één cel gelijk en in vijf cellen lager. Niet iedere numerieke afwijking is volgens de bootstrapanalyse statistisch onderscheidbaar.

6.1 Skills en modellen zijn complementair

Een van de meest relevante resultaten: Qwen-3.5-9B met WikiSkill haalt 47,4, terwijl Qwen-3.6-27B zonder skills 39,4 haalt. Een kleiner model met goede procedurele ondersteuning kan dus een aanzienlijk groter model zonder dergelijke ondersteuning verslaan.

Dat betekent niet dat skills grotere modellen overbodig maken. Het tegenovergestelde lijkt zelfs het geval. De absolute winst neemt binnen de drie Qwen-configuraties toe van 12,3 naar 17,5 en vervolgens 23,9 procentpunt. Sterkere modellen lijken beter in staat om complexe procedures correct uit te voeren.

Een bruikbaarder capaciteitsmodel is daarom:

Agentprestatie ≈ modelcapaciteit × skillkwaliteit × model-skill-fit × harnessintegriteit

Meer modelparameters zijn slechts één factor. Een slecht ontworpen harness, verkeerde procedure of incompatibele skill kan de voordelen van een sterker model volledig neutraliseren.

6.2 De paper verwart soms procent en procentpunt

De introductie beschrijft de Qwen-verbeteringen als respectievelijk 12,3%, 17,5% en 23,9%. De tabellen laten echter zien dat dit absolute verschillen in procentpunten zijn. Voor Qwen-3.5-4B geldt: 38,5 - 26,2 = 12,3 procentpunt. De relatieve verbetering is (38,5 - 26,2) / 26,2 ≈ 46,9%. Dit verandert de inhoudelijke conclusie niet, maar het onderscheid is wetenschappelijk relevant. Zeker bij grote verbeteringen kan verwisseling van procenten en procentpunten tot misinterpretatie leiden.

7. Niet iedere taak is even skillbaar

De grootste verbeteringen ontstaan bij taken die zich laten vertalen naar herhaalbare procedures. Voor Qwen-3.6-27B:

Benchmark	Verbetering
SpreadsheetBench	+40,9 procentpunt
LiveMath	+28,0 procentpunt
ALFWorld	+24,8 procentpunt
SealQA	+14,1 procentpunt
OfficeQA	+11,6 procentpunt

Spreadsheettaken bevatten stabiele algoritmische patronen, zoals dataframes correct laden, formules behouden, datatypes controleren, bewerkingen valideren en bestanden in het vereiste formaat wegschrijven. Dergelijke patronen zijn goed te codificeren als procedurele instructies.

OfficeQA vraagt daarentegen om navigatie door lange documenten. Kleine modellen kunnen de procedure begrijpen, maar verliezen tijdens lange contexten de instructiediscipline. Qwen-3.5-4B daalt hier zelfs van 30,2 naar 28,5. De auteurs constateren dat het model terugvalt op zijn standaard leesgedrag in plaats van de gedetailleerde zoekprocedure te volgen. Dit suggereert dat skillkwaliteit en skilluitvoerbaarheid verschillende eigenschappen zijn. Een procedure kan correct zijn, maar te complex voor een bepaald model, contextvenster of interactiebudget.

8. Cross-model transfer is de belangrijkste uitkomst

De interessantste bijdrage van de paper is mogelijk niet de gemiddelde prestatieverbetering, maar de overdracht van skills tussen modellen. Voorbeelden:

• Qwen-3.5-9B behaalt op SpreadsheetBench 24,3 zonder skill, 33,6 met een zelfontwikkelde skill en 50,5 met een skill ontwikkeld door Qwen-3.6-27B.
• Gemma-4-31B behaalt op LiveMath 33,9 zonder skill, 56,7 met een zelfontwikkelde skill en 73,7 met een Qwen-3.6-27B-skill.
• Een skill ontwikkeld door Qwen-3.5-4B brengt Gemma-4-31B op LiveMath naar 73,1.
• Qwen-3.5-9B behaalt op ALFWorld 63,4 met zijn eigen skill, maar 70,2 met een Qwen-3.6-27B-skill.

Dit ondersteunt de hypothese dat twee capaciteiten van elkaar moeten worden onderscheiden: skill discovery (het herkennen en formuleren van een nuttige procedure) en skill execution (het betrouwbaar uitvoeren van die procedure). Een model dat zelf geen optimale skill kan ontdekken, kan een elders ontwikkelde skill mogelijk uitstekend uitvoeren. Andersom kan een model een goede procedure ontdekken die het zelf niet stabiel kan volgen. Dat opent de deur naar een federatief skillmodel waarin gespecialiseerde agents procedures ontwikkelen die door andere agents worden gebruikt.

8.1 Skills zijn geen universeel overdraagbare artefacten

De transferresultaten bevatten ook een zeer belangrijke waarschuwing. Een SpreadsheetBench-skill van Qwen-3.5-4B verlaagt Gemini-3.5-Flash van 50,5 naar 18,1. Een skill van Qwen-3.6-27B verhoogt hetzelfde Gemini-model juist naar 63,4. Volgens de foutanalyse bevat de skill van het kleine model laag-niveau workarounds, zoals geïsoleerde Python-commando's en specifieke stringconversieregels. Deze helpen het kleinere model om lokale fouten te vermijden, maar beperken een sterker model dat anders een geïntegreerd end-to-end script zou produceren.

Een skill heeft daarom geen universele kwaliteitsscore. De waarde van een skill is een relationele eigenschap:

G(s, m, d, u, c) = R(m, d | s, u, c) - R(m, d | ∅, u, c)

waarbij s de skill is, m het doelmodel, d het taakdomein, u de beschikbare tools en c het context- en interactiebudget. Een skillregister moet dus niet alleen vastleggen wat een skill doet, maar ook: met welk bronmodel de skill is ontwikkeld, op welke doelmodellen zij is getest, voor welke taakdistributie zij geldig is, welke tools en permissies zij verwacht, welk contextvenster en interactiebudget nodig zijn, waar negatieve transfer is waargenomen, en wanneer zij voor het laatst is gevalideerd. Een skill is geen document. Een skill is een versieerbaar gedragsartefact met een compatibiliteitsmatrix.

9. Wat de ablation study wel en niet bewijst

De paper onderzoekt afzonderlijk of de inference-agent en de Skill Proposer toegang tot de wiki moeten krijgen. De belangrijkste resultaten voor Gemini-3.5-Flash:

Configuratie	Gemiddelde score
Geen skills	40,4
Geen proposer-wiki	48,7
Proposer-wiki, inference-agent zonder wiki	63,7
Proposer-wiki, inference-agent eveneens met wiki	60,9

Wanneer de inference-agent geen wiki krijgt, verbetert toegang tot persistente kennis voor de proposer de gemiddelde score van 48,7 naar 63,7, een winst van 15 procentpunt. Wanneer de inference-agent tijdens de training óók toegang krijgt tot de wiki, daalt de score van 63,7 naar 60,9. Op LiveMath daalt zij zelfs van 72,6 naar 64,8.

9.1 Meer context is niet altijd beter

De vermoedelijke verklaring is methodologisch interessant. Wanneer de inference-agent de wiki kan gebruiken, kan hij een taak oplossen met informatie die nog niet in de actieve skill is opgenomen. De resulterende trace geeft dan geen zuiver beeld van de kwaliteit en tekortkomingen van de skill. De trainingsobservatie wordt als het ware vervuild door een verborgen hulpmiddel.

Dit ondersteunt een breder architectuurprincipe: een component die gedrag diagnosticeert, mag tijdens de meting niet beschikken over kennis of privileges die in de uiteindelijke uitvoeringsconfiguratie ontbreken. Het is vergelijkbaar met een softwaretest die alleen slaagt doordat testdata of debugcode beschikbaar is die in productie niet bestaat. Deze bevinding ondersteunt sterke rol- en contextscheiding binnen multi-agentarchitecturen. Een agent moet alleen toegang krijgen tot de informatie die voor zijn rol noodzakelijk is.

9.2 De ablation is causaal niet zuiver

De auteurs stellen dat de ablation het belang van persistente wikikennis bevestigt. Dat is aannemelijk, maar niet volledig bewezen. Wanneer de Skill Proposer geen wikitoegang krijgt, verwijderen de onderzoekers ook de Wiki Maintainer. Daardoor veranderen tegelijkertijd meerdere factoren: wel of geen persistente kennis, wel of geen aparte analyse-agent, wel of geen extra LLM-call, wel of geen gestructureerde patroonextractie, wel of geen bijgewerkte index, en wel of geen consolidatie van successen en mislukkingen. De gemeten winst kan daardoor niet volledig worden toegeschreven aan persistentie alleen.

Een zuiverder experimenteel ontwerp zou onder gelijke compute minimaal de volgende condities moeten vergelijken: geen maintainer en geen wiki; een maintainer met een samenvatting die iedere iteratie wordt gewist; persistente maar ongestructureerde historie; persistente gestructureerde wiki; persistente wiki met willekeurig geschudde of irrelevante patronen als placebo; persistente wiki waarin alleen succesvolle interventies worden bewaard; en persistente wiki waarin ook verworpen interventies worden bewaard. Pas dan kan worden vastgesteld welk deel van het resultaat afkomstig is van persistentie, structuur, rolverdeling, negatieve kennis of extra optimizercompute.

10. Methodologische beperkingen

10.1 Adaptieve overfitting op kleine validatiesets

De validatiesets bevatten slechts 10 tot 40 voorbeelden. Hierdoor verandert de validatiescore per extra correct antwoord met:

Benchmark	Validatieomvang	Eén voorbeeld vertegenwoordigt
SealQA	10	10,0 procentpunt
LiveMath	18	5,6 procentpunt
ALFWorld	18	5,6 procentpunt
OfficeQA	24	4,2 procentpunt
SpreadsheetBench	40	2,5 procentpunt

Een kandidaat-skill wordt geaccepteerd zodra zij de eerder beste validatiescore overtreft. Eén toevallig extra correct voorbeeld kan dus voldoende zijn voor deployment. Daar komt bij dat dezelfde validatieset iteratief wordt geraadpleegd. Hoewel de proposer de voorbeelden niet rechtstreeks hoeft te zien, worden de acceptatie-uitkomsten teruggeschreven naar skill-impact.md en daarmee onderdeel van de volgende optimalisatieronde. Dit is een vorm van adaptieve data-analyse. De validatieset verandert functioneel langzaam in trainingsfeedback.

De auteurs erkennen dat de validatiesets klein zijn en middelen daarom de testprestaties over drie onafhankelijke evolutionaire runs. De bootstrapanalyse reduceert onzekerheid over de uiteindelijke testscore, maar repareert niet automatisch de adaptieve overfitting die tijdens de gating kan ontstaan. Een illustratief geval is Gemini-3.5-Flash op ALFWorld. Het model behaalt 100% op de validatieset en 85,9% op de testset. Omdat de validatiescore al maximaal is, stopt de evolutionaire loop voordat een skill kan worden ontwikkeld. Dat is een legitieme implementatieregel, maar toont ook dat een kleine validatieset ten onrechte de indruk kan geven dat geen verdere verbetering mogelijk is.

Een production-grade gate zou daarom moeten werken met een minimale effectgrootte, betrouwbaarheidsintervallen, herhaalde onafhankelijke validatieruns, een afgeschermde canary-holdout, correctie voor sequentiële hypothesetoetsing, en aparte performance- en safety-holdouts.

10.2 Drie runs zijn nuttig, maar beperkt

De volledige evolutie wordt driemaal uitgevoerd. Dat is beter dan één run, maar nog dun voor een stochastische multi-agentoptimizer. De beschreven bootstrapmethode resamplet taakinstanties. Uit de beschrijving blijkt niet duidelijk dat ook de variantie tussen de drie onafhankelijk ontwikkelde skillsets hiërarchisch wordt geresampled. Een robuustere analyse zou twee onzekerheidsniveaus modelleren:

totale variantie = variantie tussen taken + variantie tussen evolutionaire runs

Daarvoor is een hiërarchische bootstrap of mixed-effects-model geschikter. Daarnaast vermeldt de paper geen correctie voor het grote aantal afzonderlijke model-, methode- en benchmarkvergelijkingen. De macro-gemiddelden zijn overtuigend, maar individuele significantieclaims moeten voorzichtig worden geïnterpreteerd.

10.3 De scaling claim is geconfound

De paper concludeert dat het voordeel van skill-evolutie toeneemt met modelscale. De drie Qwen-configuraties zijn echter niet alleen verschillende groottes: 4B en 9B zijn Qwen 3.5, 27B is Qwen 3.6. Parameteromvang, modelgeneratie, trainingsdata, post-training en architectuur veranderen daardoor mogelijk tegelijkertijd. De resultaten tonen overtuigend dat het sterkste onderzochte Qwen-model het meest van WikiSkill profiteert. Zij bewijzen geen gecontroleerde scaling law waarin alleen het aantal parameters varieert. Een nauwkeuriger formulering zou zijn: binnen de onderzochte Qwen-configuraties correleert hogere modelcapaciteit met grotere absolute skillwinst. Voor een causale scaleconclusie zijn meerdere groottes uit dezelfde modelserie en dezelfde trainingsreceptuur nodig.

10.4 Cross-model transfer is geen cross-domain generalisatie

De skills worden voor iedere benchmark afzonderlijk ontwikkeld. Vervolgens worden zij op hetzelfde benchmarkdomein naar andere modellen overgedragen. Dat bewijst modelportabiliteit binnen een taakdistributie. Het bewijst niet dat een SpreadsheetBench-skill ook generaliseert naar onbekende spreadsheetsystemen, nieuwe bibliotheken of werkelijk bedrijfsgebruik. Aanvullende experimenten zijn nodig met nieuwe taakdistributies, gewijzigde tools en API's, temporele datasetverschuiving, adversarial inputs, onbekende bestandsstructuren, realistische permissiebeperkingen en fouten buiten de trainingsontologie. Ook is de bron-doelmatrix niet volledig. Slechts een subset van de modellen wordt als skillbron geëvalueerd.

10.5 OfficeQA is niet volledig open-world

OfficeQA wordt gepresenteerd als een long-context documenttaak. De agent krijgt echter vooraf geparste oracle-referentiepagina's als initiële documentinformatie, naast toegang tot lokale zoektools. Dat is een verdedigbare benchmarkopzet, maar eenvoudiger dan een enterpriseomgeving waarin de agent eerst zelf moet bepalen welke documenten relevant zijn, welke versie rechtsgeldig is, welke bron authentiek is, welke pagina of tabel de juiste context bevat, en of documenten elkaar tegenspreken. De resultaten moeten daarom niet rechtstreeks worden vertaald naar open-world juridisch of financieel documentonderzoek.

10.6 De O(1)-claim is te smal

WikiSkill gebruikt full-batch optimalisatie, waarbij B = N_train. De Wiki Maintainer gebruikt één call per iteratie en de Skill Proposer ongeveer 10 tot 20 ReAct-calls. Daardoor is het aantal optimizer-API-calls volgens de auteurs onafhankelijk van het aantal trainingstaken: C_WikiSkill = 1 + T_ReAct. Dit is formeel correct voor de gekozen definitie van optimizer-callcomplexiteit. Het is echter geen O(1)-claim voor de totale systeemkosten.

De volgende onderdelen schalen nog steeds met de hoeveelheid werk: inference-rollouts over alle trainingstaken, toolaanroepen, uitvoeringstijd van scripts, opslag van raw traces, netwerk- en zoekverkeer, omvang van de taakresultaatsamenvatting, omvang van wiki en skillcontext, en validatie- en testuitvoeringen. Bovendien zijn 10 tot 20 interactieve proposer-calls per iteratie niet triviaal. Een economische vergelijking moet daarom rapporteren:

totale kosten = tokens + toolcompute + omgevingstijd + validatieruns + opslag + menselijke assurance

De paper rapporteert geen volledige kosten-, latency- of energieanalyse.

10.7 Reproduceerbaarheid is nog onvolledig

Sterke punten zijn dat de paper het algoritme beschrijft, de prompts publiceert, de datasetsplits rapporteert, de modellen specificeert en de tracebudgetten documenteert. In versie 1 is echter geen implementatierepository gespecificeerd. Ook zijn geen volledige decodingparameters, zoals temperatuur, top_p, tokenlimieten en concrete random seeds, zichtbaar in de paper. Hierdoor zal onafhankelijke replicatie moeilijker zijn, vooral bij gesloten modellen die in de loop van de tijd kunnen veranderen.

11. Het ontbrekende hoofdstuk: security

WikiSkill verwerkt agentervaring alsof die ervaring epistemisch neutraal is. Dat is in productie niet houdbaar. Een agenttrace kan afkomstig zijn uit een website, een e-mail, een PDF, een spreadsheet, een API-response, een code repository, een andere agent, of een door een aanvaller gecontroleerde tooloutput. Deze bronnen kunnen indirecte promptinjecties, gemanipuleerde instructies, persoonsgegevens, secrets of kwaadaardige code bevatten.

OWASP benoemt promptinjectie, toolmisbruik, data-exfiltratie, memory poisoning, buitensporige autonomie en supply-chainaanvallen als centrale agentrisico's. Voor persistent geheugen adviseert OWASP onder meer validatie vóór opslag, geheugenisolatie, vervaltermijnen, auditing op gevoelige data en cryptografische integriteitscontroles.

11.1 Van promptinjectie naar persistent beleid

WikiSkill introduceert een potentiële aanvalsketen:

Kwaadaardige externe content
        ↓
Raw execution trace
        ↓
Samenvatting door Wiki Maintainer
        ↓
Persistent wiki-pattern
        ↓
Skillpatch door Skill Proposer
        ↓
Validatie op taakprestatie
        ↓
Actieve, overdraagbare skill

Een tijdelijke promptinjectie kan hierdoor veranderen in een persistente gedragswijziging. De aanval hoeft niet rechtstreeks een skillbestand te wijzigen. Het is voldoende dat kwaadaardige informatie door de Wiki Maintainer wordt geïnterpreteerd als een nuttige strategie. Wanneer de resulterende skill de benchmarkprestatie verbetert, kan zij de functionele gate passeren, zelfs wanneer zij ongewenst netwerkverkeer veroorzaakt, gevoelige bestanden uitleest, logging uitschakelt, validatiestappen overslaat, onnodig brede tools gebruikt of gegevens naar een externe bestemming verstuurt. De huidige gate optimaliseert taakscore, niet veiligheid. Dit kan worden aangeduid als persistent prompt-to-policy injection: onbetrouwbare content wordt via een leerketen omgezet in duurzaam uitvoerbaar beleid.

11.2 Overdraagbaarheid vergroot ook de blast radius

De paper demonstreert dat skills tussen modellen kunnen worden overgedragen. Dat betekent dat ook een gecompromitteerde skill tussen modellen, nodes en agentfamilies kan worden verspreid. Kennis die goed overdraagbaar is, maakt ook compromittering overdraagbaar. Een centrale skillregistry zonder provenance, signing en model-specifieke validatie kan daardoor een supply-chainmultiplicator worden. OWASP adviseert voor agentic skills onder meer geverifieerde publishers, cryptografische signing, versiepinning, geautomatiseerde scanning, permission manifests, sandboxing, netwerkbeperkingen, inventarisatie, approvalworkflows en uitgebreide auditlogging.

11.3 Onveranderlijke traces en privacy

De Raw Layer wordt in WikiSkill als immutable behandeld. Voor experimentele benchmarks is dat overzichtelijk. In bedrijfsomgevingen kunnen traces echter persoonsgegevens, credentials, documenten of vertrouwelijke bedrijfsinformatie bevatten. De AVG vereist onder meer doelbinding, dataminimalisatie en opslagbeperking. Onder bepaalde voorwaarden bestaat bovendien een recht op verwijdering. Een absoluut onveranderlijke opslaglaag zonder retentie-, redacteer- of verwijderingsmechanisme is daarom niet zonder meer geschikt voor persoonsgegevens.

De juiste enterpriseconstructie is: auditbewijs blijft aantoonbaar en tamper-evident, terwijl actieve persoonsgegevens niet onbeperkt aanwezig blijven. Dat vraagt om pseudonimisering, DLP vóór persistentie, secretredactie, gescheiden encryptiesleutels, retentiebeleid per datatype, cryptografische tombstones, herleidbare verwijdering, en opslag van hashes in plaats van volledige content waar mogelijk.

12. Van WikiSkill naar Assured WikiSkill

Een production-grade variant moet niet alleen taakprestatie optimaliseren, maar meerdere harde en zachte criteria combineren. Een veiligere acceptatiefunctie is bijvoorbeeld:

Accept(S') ⇔ Pr(ΔQ groter dan ε) ≥ 1 - α ∧ Risk(S') ≤ τ ∧ Policy(S') = PASS ∧ Cost(S') ≤ B

waarbij Q de taakprestatie is, ε de minimale relevante verbetering, α de toegestane statistische onzekerheid, Risk het beveiligings- en compliancerisico, τ de risicotolerantie, Policy de harde policy-as-code-gate en B het beschikbare kostenbudget. Een skill wordt dus niet geaccepteerd omdat zij alleen beter scoort. Een skill wordt geaccepteerd wanneer zij aantoonbaar beter presteert, geen bestaande werking regressief beïnvloedt, geen nieuwe veiligheidsgrens overschrijdt, compatibel is met het doelmodel en de tools, binnen kosten- en latencybudgetten blijft, en voldoende provenance en uitlegbaarheid heeft.

NIST benadrukt dat test, evaluatie, verificatie en validatie gedurende de gehele AI-levenscyclus moeten plaatsvinden. Het AI RMF vraagt daarnaast om documentatie van generaliseerbaarheidsbeperkingen, monitoring in productie, menselijke oversight en traceerbaarheid van ontwerp- en deploymentbeslissingen.

13. Voorgestelde enterprise-referentiearchitectuur

13.1 Evidence Plane

De Evidence Plane ontvangt agenttraces, maar schrijft deze niet ongefilterd weg. Vereiste functies: provenance per observatie, bronauthenticiteit, trustclassificatie, content- en instruction-separatie, promptinjectiedetectie, DLP en secret scanning, malware- en scriptanalyse, inhoudelijke hashing, tenant- en sessie-isolatie en retentiebeleid. Iedere observatie krijgt een label, bijvoorbeeld:

source_trust: untrusted_external
content_type: web_document
contains_instructions: possible
pii_status: redacted
integrity_status: verified
allowed_for_learning: false

Onbetrouwbare content mag niet automatisch als leerbewijs worden gebruikt.

13.2 Epistemic Plane

De wiki moet niet alleen tekstpagina's bevatten, maar expliciete claims:

claim_id: KCL-2026-00421
claim: "Bij fouttype X voorkomt procedure Y herhaling"
status: provisional
confidence: 0.71
valid_from: 2026-08-30
valid_until: 2026-11-30
supporting_evidence:
  - trace:TR-1982
  - trace:TR-2011
contradicting_evidence:
  - trace:TR-2033
source_trust: mixed
security_taint: none_detected

Iedere kennisclaim moet ondersteuning, tegenspraak, onzekerheid en tijdsgebondenheid kunnen uitdrukken. Belangrijk is dat twee vormen van persistentie worden onderscheiden: append-only historie (wat op welk moment bekend of voorgesteld was) en actieve kennisview (wat momenteel als bruikbaar en voldoende betrouwbaar geldt). De historische ledger mag onveranderlijk zijn. De actieve view moet retractions, supersession, expiry en confidence decay ondersteunen. De paper kiest voor "wiki nooit terugrollen". Enterprise-grade kennisbeheer vraagt een subtielere regel: verwijder het auditbewijs niet, maar maak foutieve kennis wel intrekbaar.

13.3 Skill Registry

Iedere skill wordt een ondertekend artefact met minimaal:

skill_id: SKL-SPREADSHEET-017
version: 2.4.1
owner: data-agent-team
source_model: qwen-3.6-27b
validated_targets:
  - qwen-3.6-27b
  - gemma-4-31b
unsupported_targets:
  - gemini-3.5-flash
permissions:
  filesystem: workspace_only
  network: denied
  shell: restricted
tool_contract:
  - python
  - libreoffice-headless
context_budget: 24000
evidence_lineage:
  - KCL-2026-00421
security_tests:
  prompt_injection: pass
  exfiltration: pass
  path_traversal: pass
valid_until: 2026-10-31
signature: cosign://...

Een PURPOSE.md is waardevol voor mensen, maar moet worden aangevuld met machine-readable policy- en provenancegegevens.

13.4 Assurance Plane

De assurancepipeline bevat ten minste unit tests per skill, regressietests, sealed holdouttests, adversarial promptinjectietests, memory-poisoningcanaries, tool-abuse- en privilege-escalatietests, data-exfiltratietests, model-skill-transfermatrix, context- en tokenbudgettests, latency- en kostentests, en menselijke approval voor high-impact skills. De lifecycle wordt:

DRAFT → QUARANTINED → FUNCTIONALLY_VALIDATED → SECURITY_VALIDATED → TRANSFER_VALIDATED → CANARY → ACTIVE → DEPRECATED → REVOKED

Geen enkele proposer mag zijn eigen skill zelfstandig valideren en activeren. Separation of duties is noodzakelijk.

13.5 Runtime Enforcement Plane

De runtime mag niet vertrouwen op instructies in SKILL.md als primaire veiligheidsgrens. Beperkingen moeten buiten het model worden afgedwongen: deny-by-default netwerkbeleid, read-only filesystems waar mogelijk, sandboxing, resourcequota, command allowlists, egressproxy's, parametergebonden approvals, workload identity via OIDC, audience-restricted en kortlevende tokens, minimale OAuth2-scopes, automatische tokenredactie uit traces, en kill switches en circuit breakers. Een skill kan beschrijven wat een agent zou moeten doen. Alleen externe policy enforcement kan bepalen wat de agent daadwerkelijk mág doen.

14. Vertaling naar een enterprise-agentecosysteem

WikiSkill sluit inhoudelijk sterk aan bij de richting van moderne agentplatforms, maar moet niet als losstaande agentloop worden toegevoegd. De natuurlijke mapping:

WikiSkill	Enterprise-component
Raw Layer	Federatie-events, agenttraces, evidence graph
Wiki Layer	Claim ledger, genormaliseerde kennis, epistemische states
Skills Layer	Skills van de eigen agenten
Skill impact log	Assurance evidence en wijzigingshistorie
Validation gate	Assurance gates en false-green canaries
Cross-model transfer	Capability registry en model-skill compatibility matrix
Rollback	Control plane en versioned artifact registry

14.1 Geen tweede waarheidssysteem bouwen

De Wiki Layer moet niet naast een bestaande evidence graph en claim ledger een tweede epistemisch systeem vormen. Beter is:

Raw agent traces
        ↓
Evidence normalization
        ↓
Claim Ledger
        ↓
Epistemische evaluatie
        ↓
Curated knowledge view
        ↓
Skill proposer
        ↓
Assurance pipeline
        ↓
Signed skill registry

De Wiki Maintainer kan hierbij functioneren als claim- en hypothesegenerator, maar niet als autonome bron van waarheid.

14.2 Integratie met een epistemische evaluatielaag

Een epistemische evaluatielaag kan voor iedere voorgestelde skill controleren of de onderliggende claims voldoende bewijs hebben, of subject, relatie, conditie en polariteit behouden blijven, of ondersteunend en tegensprekend bewijs correct is verwerkt, of de skill meer claimt dan het bewijs rechtvaardigt, of een eerdere afwijzing wordt omzeild via semantisch equivalente formulering, en of de validatie een mogelijke false green bevat. Dit is precies waar WikiSkill zelf nog zwak is. De paper bewaart proposaldiffs en scores, maar voert geen expliciete epistemische validatie uit op de inhoud van het patroon of de skill.

14.3 Cross-node skill transfer

Een federatie heeft meerdere modellen met verschillende capaciteiten. WikiSkill suggereert dat skill discovery bewust aan een ander model kan worden toegewezen dan skill execution. Een mogelijke orchestratiestrategie:

Sterk diagnosemodel
    ontwikkelt kandidaat-skill
Epistemische evaluatielaag
    valideert bewijs en semantiek
Security-agent
    voert threat modeling en adversarial tests uit
Doelmodellen
    voeren transfercanaries uit
Control plane
    activeert skill per compatibele node

De registry selecteert dan niet alleen een agent op capability, maar op de combinatie (agent, model, skillversie, toolcontract). Dat voorkomt dat een skill die veilig en effectief is op de ene node automatisch ook op een andere node wordt geactiveerd.

15. Aanbevolen implementatieroadmap

Fase 0, architectuur en threat model. Definieer eerst TraceEnvelope, KnowledgeClaim, SkillArtifact, ValidationEvidence, TransferResult en RevocationEvent. Voer threat modeling uit op indirecte promptinjectie, memory poisoning, skill supply chain, credential leakage, cross-agent propagation, validation gaming en rollback bypass.

Fase 1, offline onderzoeksproef. Gebruik alleen synthetische data, read-only tools, geïsoleerde containers, lokale modellen, vaste benchmarksets en geen netwerktoegang tijdens skilluitvoering. Doel is niet maximale performance, maar het aantonen van correcte provenance, reproduceerbare skillgeneratie, deterministische rollback, foutdetectie, intrekking van wikikennis en bescherming tegen poisoned traces.

Fase 2, transfermatrix. Test iedere skill systematisch op verschillende modellen, contextgroottes, toolversies en permissies. Leg positieve én negatieve transfer vast.

Fase 3, federatieve canary. Activeer alleen op laag-risico, read-only workflows: documentclassificatie, metadata-extractie, niet-kritische research, sandboxed data-analyse en contentkwaliteitscontrole. Gebruik een klein verkeerspercentage en automatische rollback.

Fase 4, gecontroleerde productietoepassing. Schrijvende of extern zichtbare acties worden pas toegestaan na een security gate, epistemische gate, functionele gate, privacy gate, human approval en een volledig aantoonbare audit trail. High-impact juridische, bestuurlijke of securitybeslissingen blijven buiten autonome skill-evolutie.

16. Onderzoeksagenda

Voordat WikiSkill als volwassen patroon kan gelden, zijn zes onderzoekslijnen nodig.

Ten eerste, causale isolatie. Onderzoek moet persistentie, structuur, extra compute en rolverdeling afzonderlijk ableren.

Ten tweede, betrouwbare adaptieve validatie. De gate moet bestand zijn tegen herhaald gebruik van kleine validatiesets.

Ten derde, distributieverschuiving. Skills moeten worden getest op nieuwe taken, gewijzigde tools, temporele drift en adversarial omgevingen.

Ten vierde, veilige kenniscompilatie. Er is onderzoek nodig naar provenance, taint tracking en het voorkomen dat indirecte promptinjecties worden gecompileerd tot persistent gedrag.

Ten vijfde, lifecyclemanagement. Wiki's hebben pruning, expiry, retractions, contradictiedetectie en confidence decay nodig.

Ten zesde, economische evaluatie. Call count alleen is onvoldoende. Tokengebruik, toolcompute, latency, energie, opslag en menselijke assurance moeten worden meegenomen.

Conclusie

WikiSkill laat overtuigend zien dat agentprestaties niet alleen worden bepaald door het onderliggende model. Een expliciete architectuur voor het verzamelen, consolideren, falsificeren en operationaliseren van ervaring kan tientallen procentpunten winst opleveren.

De paper ondersteunt drie belangrijke conclusies. Ten eerste, procedurele kennis en modelcapaciteit zijn complementair. Een kleiner model met goede skills kan een groter model zonder skills verslaan. Ten tweede, skill discovery en skill execution zijn verschillende capaciteiten. De beste skill voor een model hoeft niet door dat model zelf te zijn ontwikkeld. Ten derde, persistente kennis verbetert cumulatief leren, maar alleen wanneer zij buiten de uitvoeringsagent wordt gehouden en gericht wordt gebruikt voor skillontwikkeling.

De empirische resultaten zijn sterk, maar de causale en productionele conclusies moeten worden begrensd. De kleine, herhaald gebruikte validatiesets, de geconfounde scalingvergelijking, de onvolledige transfermatrix, het ontbreken van een volledige kostenanalyse en de beperkte reproduceerbaarheid maken onafhankelijke replicatie noodzakelijk.

Het grootste ontbrekende element is security. Een systeem dat ervaring automatisch omzet in persistente kennis en vervolgens in uitvoerbaar gedrag, bouwt feitelijk een autonome software supply chain. Zonder provenance, signing, policy enforcement, adversarial testing en epistemische assurance kan WikiSkill niet alleen goede strategieën institutionaliseren, maar ook fouten, vooroordelen en aanvallersinstructies.

De blijvende bijdrage van deze paper is daarom niet noodzakelijk de wiki zelf. Het is het architectuurprincipe: scheid observaties, kennisclaims en uitvoerbaar gedrag. Bewaar negatieve ervaring. Maak gedrag reversibel. Maak kennis intrekbaar. Activeer alleen wat functioneel, statistisch, epistemisch en beveiligingstechnisch is gevalideerd. Met die aanvullende waarborgen kan WikiSkill uitgroeien tot een belangrijke basis voor cumulatief lerende agents. Zonder die waarborgen automatiseert het systeem niet alleen leren, maar ook de institutionalisering van fouten.