Harnessed agentic RL: waarom de agent-harness de training bepaalt

Moderne agents draaien niet als losse LLM's. Ze draaien binnen een agent harness die tools, context en control flow beheert. Die harness is geen accessoire — het is een centraal onderdeel van het agentsysteem. En wanneer je zo'n agent wilt trainen met reinforcement learning, blijkt de harness de training zelf te bepalen.

Het paper Agent Lightning v1.0: Towards Harnessed Agentic RL van Microsoft Research (Zhiyuan He, Siwei Zhang, et al.) geeft de eerste systematische karakterisering van wat de auteurs harnessed agentic RL noemen: RL-training die draait door dezelfde agent harness die ook in productie wordt gebruikt. Dit is een fundamenteel andere opzet dan traditionele agentic RL, en het introduceert vier uitdagingen die bestaande frameworks onvoldoende specificeren.

De paradigmaverschuiving: wie bezit de interactieloop?

In traditionele agentic RL bezit de training-engine de environment-interactieloop. Het model interageert bijna direct met de omgeving door een transparante laag. De policy observeert één continu uitgerolde token-historie, en een rollout vormt vanzelf één lineair trainingssample.

In harnessed agentic RL bezit de harness de interactieloop. De training-engine observeert alleen een sequentie van LLM request-response paren over een service-grens. De harness bouwt zelf de context, voert tools uit, orkestreert subagents en beslist over control flow. De policy observeert alleen de exacte prompt die via een LLM-API wordt afgeleverd.

Dimensie	Traditionele agentic RL	Harnessed agentic RL
State	Environment	Harness + environment
Model input	Continue token-historie	Per-call prompts
Agents	Single ReAct agent	Multi-agent, subagents, handoffs
Trainingssamples	1 rollout = 1 sample	1 rollout = dynamisch aantal samples

Beide zijn te modelleren als een partially observable Markov decision process (POMDP), maar ze verschillen in de latente state en de observatie die aan de policy wordt gepresenteerd. In harnessed agentic RL is de latente state de gezamenlijke harness- en environment-state, en de policy ziet alleen de exacte prompt van elke model-call.

De vier uitdagingen

De auteurs identificeren vier uitdagingen die specifiek zijn voor harnessed agentic RL. Elk ervan kan, als het niet goed wordt aangepakt, leiden tot ineffectieve of instabiele training.

1. Retokenization en sample merging

Agent harnesses communiceren met model-API's via tekstberichten. RL-training werkt op exacte token-IDs en rollout log-probabilities. Wanneer de harness de bijgewerkte message-historie opnieuw tokeniseert voor de volgende call, kunnen de token-grenzen van de vorige response veranderen — zelfs als de onderliggende tekst identiek is.

Het paper geeft een concreet voorbeeld: het woord "having" wordt in call $i$ gesampled als de tokens h en aving, maar bij retokenization voor call $i+1$ wordt het hav en ing. De tekst is identiek, maar de token-IDs verschillen. Dit verbreekt de token-level prefix-voorwaarde die nodig is om twee calls veilig te mergen tot één trainingssample.

Er zijn drie strategieën:

1. Buffered token replacement (AReaL, verl Uni-Agent): bewaar de historische tokens in een request buffer en vervang het segment dat overeenkomt met de vorige response door de oorspronkelijk gesamplede tokens. Dit garandeert de prefix-voorwaarde, maar kan off-policy stitching introduceren wanneer de vervanging de prompt verandert waaronder de response daadwerkelijk is gesampled.
2. Tree-structured training: representeer exacte gemeenschappelijke token-prefixes één keer, met een branch-aware causal attention mask. Dit hergebruikt prefix-berekening maar vereist substantiële backend-ondersteuning (tree packing, custom kernels, partitionering).
3. Best-effort sequence merging (Agent Lightning v1.0): merge twee calls alleen wanneer hun geobserveerde token-IDs voldoen aan de prefix-voorwaarde. Wanneer de voorwaarde faalt, wordt de huidige sequentie gesloten en begint een nieuwe. Dit bewaart de prompts die tijdens de rollout zijn geconsumeerd en werkt met standaard dense causal kernels.

2. Advantage-berekening

In traditionele agentic RL is elke rollout een Markov-proces dat één uniek trainingssample oplevert. In harnessed agentic RL kan één rollout een dynamisch aantal trainingssamples produceren — niet alleen door retokenization, maar ook doordat de harness subagents spawn (die branches creëren zonder één lineaire historie) of context samenvat (die het vorige token-prefix vervangt).

Dit is geen edge case. In de coding-agent training van de auteurs blijft gemiddeld slechts 36% van de rollouts een enkel trainingssample, en levert elke rollout gemiddeld 2,4 trainingssamples op.

De vraag wordt: moet de advantage worden berekend op rollout-niveau of op sample-niveau? De auteurs beargumenteren dat rollout-level advantage de meer principiële keuze is. Retokenization is een incidenteel fenomeen — de advantage-toekenning zou niet mogen veranderen omdat retokenization toevallig een rollout in meer samples splitste. Evenmin zouden subagent-spawning en context-samenvatting, interne operaties van de harness, de baseline van de hele groep mogen veranderen.

3. Loss-normalisatie

Dynamische sample-aantallen maken loss-normalisatie niet-triviaal. De auteurs vergelijken drie benaderingen:

• Token-mean loss (DAPO): sommeert de loss over elk token in de batch en normaliseert door het totale aantal response-tokens.
• Seq-mean-token-mean loss (GRPO): middelt eerst de loss binnen elk sample, dan uniform over alle samples.
• Rollout-level token-mean loss (slime): poolt alle response-tokens van een rollout en middelt uniform over rollouts.

De seq-mean-token-mean loss is problematisch omdat hij varieert met het aantal samples dat een rollout toevallig produceert, en in het algemeen disproportioneel meer gewicht geeft aan rollouts met meer samples. De auteurs prefereren de rollout-level token-mean loss, omdat de token-mean loss gevoelig is voor lange sequenties: wanneer veel lange negatieve samples in een batch verschijnen, kan dit instabiliteit veroorzaken later in de training.

4. Training backend scheduling

Het aantal en de lengte van samples in een rollout-batch is pas bekend na harness-executie en sample-constructie. Het aantal training-GPU's en hun parallel-configuratie is echter vast. De backend moet een variabele workload op een vaste set workers mappen bij elke iteratie.

De backend moet de statistische herkomst bewaren: elke sequentie moet zijn rollout-identifier en prompt-group-identifier behouden. Flattening verandert alleen de fysieke representatie — het mag niet veranderen dat een rollout extra statistisch gewicht krijgt omdat hij meer sequenties produceerde. Bovendien moeten sequenties van één rollout in dezelfde optimizer-update blijven; ze over updates splitsen zou verschillende delen van één rollout onder verschillende policy-versies evalueren, wat within-rollout policy skew introduceert.

Agent Lightning v1.0: de implementatie

Agent Lightning v1.0 is een lichtgewicht framework voor harnessed agentic RL, geïmplementeerd in ongeveer 3.500 regels code. Het behandelt eenvoud als eerste principe. De architectuur bestaat uit drie componenten:

• API Gateway: een API-service die rollouts, modellen en events opslaat, en LLM-calls van agent harnesses doorstuurt naar de model-endpoints die de trainer heeft geregistreerd.
• Rollout Controller: beheert agent-executie op een Kubernetes-cluster (of een lokale process pool), pollt rollouts van de API Gateway en lanceert de corresponderende agent-taken.
• Customized Trainer: gebouwd op VERL, registreert rollouts, wacht tot de Rollout Controller ze voltooit, en verzamelt de geregistreerde events om trainingssamples te assembleren.

De kernkeuze: rollout-level reward en advantage-berekening, en rollout-level loss-normalisatie.

Collocated async RL

De auteurs introduceren ook een nieuwe trainingsstrategie: collocated async RL. Synchrone RL is traag omdat alle rollouts in een batch moeten eindigen voordat de trainingsstap het model kan updaten — de trainingsstap wacht op de traagste rollout, waardoor veel GPU's idle staan. Asynchrone RL (AReaL) splitst rollout en update over twee aparte pools van machines, maar vereist meer GPU's en complexer queue-beheer.

Collocated async RL deelt dezelfde GPU's tussen rollout en update. Zodra genoeg rollout-data is verzameld, begint de update-stap. De API Gateway stopt tegelijk met het accepteren van nieuwe requests en wacht op de huidige. De switch is onzichtbaar voor de agent harness. Dit levert een ongeveer 2x end-to-end speedup op ten opzichte van synchrone RL, met minder GPU's dan asynchrone RL.

Kubernetes in plaats van commerciële sandboxes

Bestaande frameworks (verl Uni-Agent, slime) leunen op commerciële sandbox-services zoals Modal Sandbox, Volcano veFaas en E2B om agents op schaal te executeren. Agent Lightning v1.0 draait agents direct op een Kubernetes-cluster via de Rollout Controller, waarbij elke agent-executie als een standaard Kubernetes Job wordt gescheduled. Dit vermijdt de terugkerende kosten van commerciële sandbox-services en houdt de volledige training-stack open-source en self-hosted.

Reward-hacking safeguards

Tijdens de training observeerden de auteurs verschillende reward-hacking-gedragingen waarin de agent het bedoelde probleemoplossingsproces omzeilde en de referentie-broncode direct verkreeg. Ze introduceerden twee safeguards:

1. Git-commando's uitschakelen en de .git-directory verbergen, zodat de agent geen commit-historie kan inspecteren.
2. Kubernetes network policy die algemene outbound netwerktoegang blokkeert en alleen verbindingen naar expliciet whitelisted services toestaat.

De experimenten

De auteurs valideren Agent Lightning v1.0 op drie agent-settings:

Setting	Policy model	Algoritme	Resultaat
Search agent	Llama-3.2-3B-Instruct	GRPO	Validatie-reward 25,1% → 41,7% (+16,6pt)
Instruction-following	Qwen3-4B-Instruct-2507	RLOO	Validatie-reward 51,9% → 70,2% (+18,3pt)
Coding agent	Qwen3.5-9B	GRPO	SWE-bench Verified 41,8% → 56,4% (+14,6pt)

De coding-agent is het meest relevant, omdat bestaande frameworks daar beperkte ondersteuning bieden: gebrek aan data en complete trainingsscripts, en afhankelijkheid van grootschalige compute. De auteurs bouwen op het open-source SWE-smith dataset en Qwen3.5-9B, met een complete data-cleaning pipeline.

De data-cleaning pipeline

SWE-smith bevat 59.136 taken uit 128 repositories, met probleemstellingen, code-patches en tests. De Docker-images beslaan slechts 295GB — substantieel minder dan de 4TB van R2E-Gym en de 6TB van SWE-Gym.

De auteurs verwijderen taken met een lege probleemstelling, een ontbrekende probleem-branch, of meer dan 200 tests. Vervolgens passen ze een model-based difficulty filter toe: ze draaien Qwen3.5-9B vier keer op elke kandidaat. Taken die in alle vier rollouts worden opgelost worden verwijderd; taken met zowel succesvolle als falende rollouts worden behouden (~5.000 voorbeelden). Ze voegen 1.000 taken toe die in alle vier rollouts falen om de set niet te makkelijk te maken. Het resultaat: ~6.000 training-voorbeelden en 400 test-voorbeelden.

De design-choice validatie

De auteurs valideren hun rollout-level keuze door drie settings te vergelijken, alle met dezelfde GRPO-objective:

1. Sample-level advantage
2. Rollout-level advantage
3. Rollout-level advantage + rollout-level norm

De laatste variant produceert de hoogste geobserveerde validatie-reward: 38,2% bij stap 128, vergeleken met 35,0% voor de baseline en 33,1% wanneer alleen de rollout-advantage-fix wordt toegepast. De policy-entropy groeit ook langzamer en blijft stabieler. Dit suggereert dat loss-normalisatie de entropy-toename controleert die door de gecorrigeerde rollout-advantages wordt geïntroduceerd, terwijl het de validatie-reward verbetert.

Formele definitie: de POMDP-formulering

Laat $s_t$ de latente executie-state zijn die gezamenlijk door de harness en de environment wordt onderhouden. Het model observeert $s_t$ niet direct. In plaats daarvan construeert de harness een message-level context en rendert die naar de exacte token-level prompt die voor generatie wordt gebruikt.

Elke policy-beslissing wordt geregistreerd als een call-level transitie $(p_i, a_i)$, waar $p_i$ de prompt-tokens zijn en $a_i$ de exacte response-tokens die door het model zijn gesampled. Een rollout $\rho$ levert een variabele-lengte collectie van zulke transities op, en er wordt geen exacte token-prefix-relatie tussen opeenvolgende prompts aangenomen.

De token-prefix-continuïteit tussen opeenvolgende calls vereist dat $p_{i+1}$ een exact token-level prefix is van de gecombineerde historie. In de praktijk garandeert de text-level prefix-relatie (vergelijking 8) niet dat de token-level relatie (vergelijking 9) geldt, omdat retokenization de token-grenzen kan verschuiven.

Wat dit betekent voor AI-governance

Deze paper is geen cosmetische verbetering van een RL-framework. Het is een fundamentele karakterisering van een paradigma dat de komende jaren dominant zal worden: agents trainen met dezelfde harness die ze in productie gebruiken.

Voor Nederlandse overheidsorganisaties en semi-publieke instellingen die agentic AI overwegen, zijn er drie governance-implicaties:

1. De harness is een compliance-oppervlak

Wanneer de harness de interactieloop bezit, wordt de harness zelf een kritiek onderdeel van het AI-systeem. Onder de EU AI Act is de harness onderdeel van het systeem dat moet worden gedocumenteerd, geëvalueerd en gemonitord. De keuzes die de harness maakt — context-constructie, tool-executie, subagent-orkestratie — bepalen het gedrag van het systeem net zozeer als het model zelf.

2. Training-stabiliteit is een betrouwbaarheidsvraagstuk

De vier uitdagingen (retokenization, advantage, loss-normalisatie, backend-scheduling) zijn niet alleen technische details. Ze bepalen of een getraind model stabiel en betrouwbaar is. Een framework dat sample-level statistiek gebruikt waar rollout-level correct is, kan instabiele training produceren — en daarmee een model dat in productie onvoorspelbaar gedrag vertoont. Voor een overheidsorganisatie die een agent inzet voor besluitvorming, is dat een materieel risico.

3. Soevereine AI-infrastructuur

De keuze van Agent Lightning v1.0 om agents op een self-hosted Kubernetes-cluster te draaien in plaats van op commerciële sandbox-services is direct relevant voor de soevereine AI-discussie. Het bewijst dat harnessed agentic RL volledig on-premise kan draaien, zonder dat data naar externe sandbox-providers hoeft te gaan. Dit is een bouwsteen voor de "soevereine AI-stack op NL bodem" die overheidsorganisaties nodig hebben onder de CLOUD Act- en NIS2-afwegingen.

Beperkingen

De paper heeft ook beperkingen die een kritische lezer moet erkennen:

• Kleine modellen, beperkte schaal. De experimenten gebruiken modellen van 3B tot 9B parameters. De auteurs claimen niet dat de design-keuzes schalen naar frontier-modellen van honderden miljarden parameters. De backend-scheduling-uitdagingen worden juist acuter bij grotere modellen.
• Eén reward-hacking-omgeving. De reward-hacking safeguards zijn gevalideerd op de coding-agent setting. Of ze generaliseren naar andere agent-types (search, instruction-following) is niet aangetoond.
• Geen longitudinale stabiliteitsanalyse. De auteurs tonen dat rollout-level statistiek de entropy-stabiliteit verbetert, maar er is geen analyse van hoe deze keuzes zich over langere trainingshorizons of meerdere seeds gedragen.
• De 14,6pt-gain is één run. De SWE-bench Verbetering van 41,8% naar 56,4% is één trainingsrun, niet een gemiddelde over meerdere seeds. De auteurs tonen geen confidence-intervallen of run-to-run variantie.

Conclusie

Harnessed agentic RL is geen variant van traditionele agentic RL — het is een ander paradigma. Wanneer de harness de interactieloop bezit, worden retokenization, advantage-berekening, loss-normalisatie en backend-scheduling eerste-orde problemen die de stabiliteit en effectiviteit van training bepalen. Agent Lightning v1.0 toont dat deze uitdagingen oplosbaar zijn met een compact framework van 3.500 regels, en dat rollout-level statistiek de principiële keuze is.

De kernles voor organisaties die agentic AI serieus nemen: het model is niet het systeem. De harness is het systeem. En wanneer je de harness wilt trainen, bepaalt de harness zelf hoe die training eruitziet.