ETCLOVG: De taxonomy van het zevenlagige agent harness, in kaart gebracht op een productie-runtime

De betrouwbaarheid van een agent is een eigenschap van zowel het model als het systeem eromheen. Een survey uit 2026 door onderzoekers van Carnegie Mellon, Yale, Amazon en andere instituten stelt ETCLOVG voor — Execution, Tooling, Context, Lifecycle, Observability, Verification en Governance — als een taxonomy voor dat omringende systeem, oftewel het agent harness.

De auteurs brengen meer dan 170 open-sourceprojecten in kaart voor de zeven lagen en identificeren zowel volwassen gebieden als operationele hiaten. Dit artikel vat de taxonomy samen en brengt deze vervolgens in kaart op het Agent Harness van TrueFoundry — waarbij native runtime-functionaliteiten worden gescheiden van aangrenzende patronen en integraties.

‍

‍

Priyanka, hoofd platform, had een betrouwbaarheidsprobleem dat ze geen naam kon geven. Haar teams beheerden vijf productie-agents, en wanneer er een misdroeg, waren de post-mortems het nooit eens over wat er gerepareerd moest worden. De een gaf de schuld aan het model en pleitte voor een upgrade. De ander herschreef de prompt. Een ander voegde een retry toe. Weer een ander wilde een sandbox. Elke oplossing was aannemelijk, elke oplossing richtte zich op een andere laag, en geen van alle deelde een vocabulaire om te zeggen welke laag daadwerkelijk gefaald had — dus bleven de vergaderingen in cirkels draaien. Wat Priyanka nodig had was geen beter model of een luidere mening; ze had een kaart nodig: een manier om naar een agent te wijzen en te zeggen "deze fout zit in lifecycle, niet in het model" of "we hebben helemaal geen verification-laag." ETCLOVG is die kaart, en dit artikel is de wandeling erdoorheen — eerst de taxonomy zoals de auteurs deze hebben opgebouwd, en vervolgens elke laag afgezet tegen een productie-runtime, waarbij onderscheid wordt gemaakt tussen native functionaliteiten en aangrenzende workflows en integraties, ongeacht of deze met deze namen worden aangeduid.

1. Waarom er überhaupt een harness-taxonomy bestaat

De centrale bewering van de survey is devaluerend ten opzichte van modellen en waardeverhogend ten opzichte van infrastructuur: de snelle uitrol van LLM-agents bracht aan het licht dat de betrouwbaarheid van de uitvoering minder afhangt van het basismodel dan van het harness dat eromheen zit. Het bewijs is deels historisch. Het ReAct-tijdperk van 2022–23 wikkelde een enkele model-loop in een while-loop, een prompt-template en een kleine tool-dispatch-tabel; AutoGPT en BabyAGI legden vervolgens de foutmodi van die dunne wrapper bloot — uitvoering die op hol slaat, context-blowout, verlies van status, niet-gemonitorde bijwerkingen — als infrastructuurproblemen in plaats van prompt-problemen. De jaren daarna heeft het vakgebied langzaam de ontbrekende infrastructuur opgebouwd en deze pas sinds kort een naam gegeven.

Die naamgeving is het driedelige kader van de survey, dat harness engineering precies lokaliseert. Prompt engineering (2022–24): de hefboom is de invoertekst, geoptimaliseerd voor een enkele call. Context engineering (2025): de vraag verschuift naar "wat moet het model bij elke stap zien?" — retrieval, compactie, tool-resultaat-ranking, window-saturatie. Harness engineering (2026–): naarmate modellen capabel genoeg worden voor langdurige taken, verbreedt de focus zich naar de gehele infrastructuur-wrapper. Elke fase omvat de vorige — harness omvat context omvat prompt — en ze overlappen elkaar in plaats van elkaar te vervangen. ETCLOVG geeft die derde fase de architectonische grenzen die de eerste twee nooit nodig hadden.

2. ETCLOVG, laag voor laag

De taxonomy valt uiteen in een structurele kern en een control plane. E, T, C en L zijn de structurele pijlers — ze zorgen dat een agent draait. O, V en G vormen de control plane — ze maken een draaiende agent waarneembaar, evalueerbaar en veilig. De opmerkelijke stap van de survey is het promoveren van Observability en Governance tot onafhankelijke lagen in plaats van ze op te nemen in lifecycle hooks, met als argument dat in productie elk van deze een eigen tooling-ecosysteem heeft en door een ander team wordt beheerd. Hier zijn de zeven lagen, geparafraseerd uit de definities van de survey.

E — Execution environment (Uitvoeringsomgeving). Waar de code en acties van de agent daadwerkelijk draaien en wat deze begrenst: beheerde sandboxen, microVMs, voor code gespecialiseerde runtimes, computer-use- en browser-omgevingen, permissiemodellen op OS-niveau. Dit is de blast-radius-laag — wat een agent kan raken wanneer hij een commando uitvoert.

T — Tool interface and protocol (Tool-interface en -protocol). Hoe externe functionaliteiten worden beschreven, ontdekt en aangeroepen: protocolstandaarden (MCP, A2A), toolbeschrijving en -selectie, tool-augmented training, sessiebeheer. Het model kent tools alleen via deze laag.

C — Context and memory management (Context- en geheugenbeheer). Wat het model kan zien over korte-termijn-, sessie- en permanente horizonten: technieken voor langetermijncontext en mitigaties voor context drift. Het onderwerp van de vorige engineeringfase, nu één pijler uit vier.

L — Lifecycle and orchestration (Levenscyclus en orchestratie). De control flow die status leest en schrijft — van de inner loop van een enkele agent tot multi-agent-patronen en volledige pipelines van issue tot pull-request. De loop zelf bevindt zich hier.

O — Observability and operations (Observabiliteit en operaties). Traces, kosten, storingen, betrouwbaarheidssignalen — tracing-platformen, agent-specifieke ops-tools, kostentracking, geïntegreerde observabiliteit. De open-sourcekaart van de survey laat zien dat deze laag in openbare code verhoudingsgewijs dun is.

V — Verification and evaluation (Verificatie en evaluatie). Het omzetten van taken en traces naar evaluatie, het toewijzen van fouten en regressiefeedback: benchmark-grounding, gecontroleerde uitvoering, beoordeling op meerdere niveaus, evaluatieloops tijdens deployment. Het verschil tussen "het heeft gedraaid" en "het was correct."

G — Governance and security (Governance en beveiliging). Beperkingen over sublagen van model, systeem en organisatie: permissiemodellen, lifecycle hooks, hardening van onderdelen, declaratieve constituties, audit-infrastructuur. De survey merkt op dat ook deze laag dun is in open source en "vaker voorkomt binnen commerciële platformen."

3. De drie cross-layer-effecten (het deel dat wringt)

De survey benadrukt dat de lagen geen onafhankelijke knoppen zijn, en de synthese tussen de lagen is waar de praktische wijsheid zit. Het kosten-kwaliteit-snelheid trilemma: sterkere sandboxen, rijkere context en diepere evaluatie verbeteren allemaal de kwaliteit, terwijl ze tokens, latentie en infrastructuur kosten — dus een productie-harness kan kwaliteit niet behandelen als een enkel getal dat gemaximaliseerd moet worden; het moet beslissen welke risico's kostbare controles rechtvaardigen en welke checks asynchroon of in een regressiesuite kunnen draaien. De afweging tussen functionaliteit en controle: grotere tool-menu's, permanent geheugen en permissieve sandboxen vergroten wat een agent kan doen, terwijl ze de blast radius van een verkeerd afgestemde of gecompromitteerde actie vergroten — wat betekent dat functionaliteit en controle geen gescheiden functies zijn, maar één ontwerpas die tool-schema's, runtime-permissies, identiteit, auditeerbaarheid en menselijke goedkeuring omvat. En het harness-koppelingsprobleem: een wijziging in één willekeurige laag kan er in isolatie voordelig uitzien, maar de gehele uitrol in combinatie verslechteren — dus wijzigingen in het harness moeten worden getest als systeemwijzigingen.

Dat laatste punt is wat in de post-mortems van Priyanka steeds over het hoofd werd gezien. Een retry die is toegevoegd op de lifecycle-laag heeft interactie met context (herhaalde uitvoer komt het window opnieuw binnen), observabiliteit (toont de trace de retry?) en kosten (elke retry kost opnieuw tokens). De waarde van ETCLOVG is niet alleen het benoemen van zeven lagen; het is het eisen dat ze in samenhang worden beschouwd — het argument voor een runtime waarin lagen samen worden ontworpen in plaats van aan elkaar te worden gelijmd.

4. Structurele pijlers op een productie-runtime: E, T, C, L

Bekijk de vier structurele lagen afgezet tegen het Agent Harness van TrueFoundry, en elk heeft een concrete implementatie. Execution (E): wanneer een sessie code-uitvoering of bestandsoperaties vereist, kan het harness op verzoek een geïsoleerde sandbox provisionen, deze hergebruiken over turns in die sessie, en de levenscyclus en opschoning ervan beheren (sandbox-documentatie) — de cel "beheerde sandbox" uit de survey, waarbij de blast-radius-grens een platformeigenschap is in plaats van een op maat gemaakte container van elk team. Tooling (T): functionaliteiten worden bereikt via de MCP Gateway — MCP als de protocolstandaard die de survey noemt, plus een registry voor discovery, beschrijvingen en selectie per tool, en sessie-/authenticatiebeheer — zodat de tool-laag wordt beheerd in plaats van handmatig verknoopt. Context (C): de context-engineering-suite van het harness — compactie, offloading van grote resultaten, code-modus, sub-agent-isolatie — is de cel "langetermijncontext en drift-mitigatie" uit de survey, het onderwerp van ons artikel over JIT-context. Lifecycle (L): de plan→act→observe-loop, sub-agent-orchestratie en human-in-the-loop-pauzes vormen de control flow die status leest en schrijft — het bereik van de inner loop van een enkele agent tot multi-agent-pipelines uit de survey.

5. De control plane in kaart brengen: Native O en G, verbonden V

Hier zijn de bevindingen van de survey specifieker dan een algemeen gat in de control plane. Observability en Governance zijn verhoudingsgewijs dun in open source en verschijnen vaker in commerciële platformen, SDK-functies of technische documentatie. Verification heeft een sterkere zichtbare dekking, hoewel het artikel een afzonderlijk gat identificeert tussen wijdverbreide tracing en minder gebruikelijke offline evaluatie. Dat maakt O en G directe onderscheidende factoren voor het platform in deze weergave; V kan beter worden behandeld als een integratie-oppervlak dat is gebouwd op de telemetrie van de runtime.

Observability (O) op de runtime is de trace per stap: elke model-call, tool-call en sandbox-uitvoering geregistreerd met kosten, tokens en latentie, geëxporteerd via OpenTelemetry (ons OTel-artikel) naar wat de rest van de stack al gebruikt. Verification (V) is momenteel een aangrenzende workflow in plaats van een native Agent Harness-evaluator. TrueFoundry biedt traces, model- en tool-metadata, routing-context en OpenTelemetry-export die online of offline evaluators kunnen voeden — het online evaluatiepatroon is gebouwd op die telemetrie, niet geleverd als een ingebouwde functie. Evaluatiebeleid, judges en promotie-gates moeten worden geïmplementeerd in de applicatie of een gekoppeld evaluatiesysteem — het "omzetten van traces naar evaluatie en regressiefeedback" uit de survey als een integratievraagstuk. Governance (G) omvat de drie sublagen van de survey: guardrails op model- en systeemniveau (invoer en uitvoer) bij de gateway, organisatorische permissiemodellen via RBAC per agent en het no-keys-referentiemodel, hardening van onderdelen en audit-infrastructuur — het onderwerp van ons artikel over governance en audit. De survey vermeldt "declaratieve constituties" onder G; het dichtstbijzijnde runtime-analogon is geversioneerde guardrail- en toegangsbeleidsconfiguratie (guardrails-documentatie).

6. Het koppelingsprobleem is het echte argument voor een platform

Het zou gemakkelijk zijn om sectie 4 en 5 te lezen als een checklist — zeven vakjes, vink ze allemaal af. De eigen synthese van de survey tussen de lagen pleit precies tegen die interpretatie, en het is de sterkste reden om te geven om de plek waar de lagen zich bevinden. Omdat de lagen gekoppeld zijn, erft een harness dat is samengesteld uit zeven onafhankelijk gekozen best-of-breed-tools het koppelingsprobleem bij elke naad: de sandbox die geen traces uitstoot die de observability-tool begrijpt; de verifier die de goedkeuringsgebeurtenissen van de governance-laag niet kan zien; de contextcompactie die stilzwijgend de gegevens verwijdert die de evaluatielaag nodig had om de run te beoordelen. Het voorschrift van de survey — test harness-wijzigingen als systeemwijzigingen — is moeilijk na te leven wanneer het systeem een harness is dat is samengesteld uit onafhankelijk geselecteerde componenten — wat integratiegrenzen creëert waar de semantiek van status, identiteit, telemetrie en beleid kan divergeren.

Dit is ook de verschuiving van framework naar platform uit de survey, geformuleerd als architectuur. Het noemt expliciet een verschuiving van agent-frameworks (die lokale abstracties verpakken: agents, tools, geheugen, loops) naar agent-platformen (die duurzame werkruimtes, identiteit, observabiliteit, evaluatie, governance en menselijke overdracht toevoegen over vele runs en vele gebruikers). Een platform is niet zomaar een framework met meer functies; het is de eenheid waarbinnen de zeven lagen samen ontworpen en gewijzigd kunnen worden. Dat maakt "koop een platform" niet het universeel juiste antwoord — een onderzoekslab dat loop-ontwerpen bestudeert, moet zijn eigen loop beheren, en elk team moet de dunne randen beheren die de eigen differentiatie vormen — maar het legt wel uit waarom het koppelingsprobleem en de verschuiving van framework naar platform voor de meeste productie-uitrollen in dezelfde richting wijzen.

7. ETCLOVG gebruiken als diagnosemiddel

De meest directe waarde van de taxonomy is niet architectonisch; het is diagnostisch, en het is wat Priyanka daadwerkelijk nodig had. Een vervolg-artikel gebruikt ETCLOVG al op precies deze manier — als een vocabulaire om runtime-bewijs te koppelen aan het harness-mechanisme dat hersteld moet worden, waarbij reparaties worden aangestuurd vanuit op traces gebaseerde foutdiagnoses in plaats van gissingen. De praktijk is om een falend traject te nemen en te vragen welke laag eigenaar is van de fout. Agent voerde een destructief commando uit zonder sandbox → E. Kocs de verkeerde tool uit een dubbelzinnige beschrijving → T. Ging achteruit gedurende een lange run naarmate het window volraakte → C. Bleef hangen in een loop bij een fout of stopte voortijdig → L. De fout was onzichtbaar totdat een klant deze meldde → O. Het "slaagde" maar leverde een verkeerd resultaat op dat niemand opmerkte → V. Het deed iets wat nooit toegestaan had mogen worden → G.

Haal de vastgelopen post-mortem van Priyanka hierdoorheen en de vergadering draait niet langer in cirkels: de engineer die de schuld gaf aan het model en degene die een retry toevoegde, grepen beiden naar oplossingen in de L-laag, terwijl de daadwerkelijke fout — een actie die is uitgevoerd zonder registratie en zonder controle — een tekortkoming in O en V was. Een upgrade van het model alleen zou daarom waarschijnlijk het onderliggende systeemgedrag niet oplossen. ETCLOVG veranderde een discussie over meningen in een vraag over lagen, wat het hele doel van een taxonomy is: niet om in het abstracte gelijk te hebben, maar om de volgende beslissing helder te maken. End-to-end runtime-traces leveren veel van het bewijs dat de diagnose nodig heeft; gekoppelde evaluators kunnen uitkomstscores en regressiesignalen op de V-laag toevoegen — een runtime plus zijn integraties en traces bij elke run geeft de diagnose zijn bewijs; de taxonomy geeft het bewijs zijn categorieën.

8. Wat de taxonomy zegt over de toekomst (en de beperkingen ervan)

De survey sluit af met open problemen, en twee daarvan zijn het waard om mee te nemen omdat ze elk "we hebben het harness opgelost"-triumfalisme temperen. Ten eerste, adaptieve vereenvoudiging: elke wrapper bevat een aanname over wat het model niet betrouwbaar alleen kan, en naarmate modellen verbeteren, blijven sommige interventies essentieel terwijl andere puur overhead worden — dus een goed harness moet zichzelf kunnen ablaten en vereenvoudigen onder gecombineerde kwaliteits-, latentie-, kosten- en risicobeperkingen. De zeven lagen zijn niet zeven dingen die gemaximaliseerd moeten worden; een deel van de huidige steigers is het dode gewicht van morgen, en een volwassen platform zou u moeten helpen te ontdekken welk deel dat is. Ten tweede, gestandaardiseerde overdrachten: de survey stelt dat een overdracht niet alleen een tekstuele samenvatting moet overdragen, maar ook intentie, beperkingen, permissies, artefacten, herkomst, budgetstatus, risiconiveau en trace-historie — een rijker contract dan welk huidig protocol dan ook draagt, en een eerlijke erkenning dat het multi-agent- en human-in-the-loop-verhaal nog niet af is.

De beperkingen zijn van belang ter wille van de eerlijkheid. ETCLOVG is een voorstel uit een survey uit 2026, geen standaard; de grenzen tussen de lagen zijn een nuttige indeling, niet de enige, en de auteurs geven expliciet aan dat de fasen elkaar overlappen en dat de codering van projecten interpretatief is. De echte bijdrage is degene die Priyanka gebruikte: een gedeeld, op de productie gebaseerd vocabulaire om precies te zeggen welk deel van de infrastructuur rond het model het werk doet, of faalt. Breng een runtime ertegenin in kaart om de lege cellen te vinden — en de eigen bevinding van de survey over het ecosysteem is dat Observability en Governance de verhoudingsgewijs dunne cellen zijn; dekking voor Verification bestaat, maar stopt vaak bij tracing, zonder evaluatie tijdens deployment — wat in deze weergave een workflow op de applicatielaag blijft die draait op de telemetrie van de runtime.

9. Veelgestelde vragen

Is ETCLOVG een industriestandaard? Nee — het is een taxonomy die is voorgesteld in "Agent Harness Engineering: A Survey" (Li et al., 2026, momenteel ter beoordeling voor TMLR), en die al wordt overgenomen als gedeeld vocabulaire door vervolgwerk over op traces gebaseerd harness-herstel. Beschouw het als een goed onderbouwde analytische lens, niet als een specificatie om tegen te certificeren. De waarde zit in het inzichtelijk en vergelijkbaar maken van harness-vraagstukken, wat waardevol is ongeacht of het ooit canoniek wordt.

Hoe verschilt dit van het onderscheid tussen harness en scaffold waar u eerder over schreef? Ze vullen elkaar aan. De scheiding tussen harness en scaffold scheidt de uitvoeringsmachinerie van de inhoud waar het model vanuit werkt; ETCLOVG zoomt in op de machinerie en ontleedt deze in zeven lagen. U kunt beide hanteren: scaffold betreft ongeveer de prompt-/context-onderwerpen uit de survey, en het harness is de E·T·C·L·O·V·G-stack die het uitvoert. ETCLOVG is de weergave met een hogere resolutie van "het harness" dat we eerder grover hadden benoemd.

Waarom zijn Observability en Governance gepromoveerd tot hun eigen lagen? Omdat ze in productie afzonderlijke tooling en afzonderlijke eigenaren hebben — de survey wijst op toegewijde observability-stacks en afzonderlijk eigenaarschap van beveiliging/governance — en het onderbrengen van deze lagen in lifecycle hooks verbergt precies de lagen die bepalen of u een agent veilig kunt beheren. De promotie is ook empirisch: de ecosysteemkaart van de survey vindt deze twee lagen het dunst in open source, wat op zichzelf een bevinding is om rekening mee te houden bij het ontwerpen.

Heb ik alle zeven lagen nodig voor elke agent? Nee, en het kosten-kwaliteit-snelheid trilemma uit de survey is daar de reden voor — elke controle kost iets, en de juiste diepte per laag hangt af van het risico en de waarde van de agent. Een interne helper met een laag afbreukrisico heeft veel minder V en G nodig dan een agent die wijzigingen in productie kan aanbrengen. Het nut van de taxonomy is hier om het weglaten bewust te maken: kies welke lagen opzet dun zijn, in plaats van het gat te ontdekken tijdens een incident.

Als ik een beheerde runtime adopteer, zit ik dan vast aan de versie van deze lagen binnen die runtime? U adopteert de implementaties van E, T, C, L, O en een groot deel van G, op dezelfde manier als u de semantiek van elke runtime adopteert. V blijft gedeeltelijk eigendom van de applicatie, tenzij u een evaluatiesysteem koppelt aan de traces en metadata van de runtime. De overdraagbare onderdelen zijn de scaffold (instructies, tooldefinities, skills) en de evaluatiecriteria — houd deze schoon en geversioneerd, en het grootste deel van uw investering verhuist met u mee. De koppeling waar de survey voor waarschuwt is precies hetgeen waarvoor u het platform betaalt om het af te handelen.

Priyanka's volgende post-mortem maakte gebruik van de kaart. Het traject legde een blinde vlek in observabiliteit en een ontbrekende verificatiecheck bloot; het team voegde een trace per stap toe en koppelde een evaluator tijdens deployment. In dit scenario richten die wijzigingen zich directer op het beschikbare systeembewijs dan een model-upgrade alleen zou doen. Dat is wat een nuttige taxonomy oplevert: niet het einde van moeilijke problemen, maar een duidelijker inzicht in welke laag eigenaar is van elk probleem. ETCLOVG benoemt de zeven lagen en eist dat teams nadenken over hun interacties, terwijl de ecosysteemkaart O en G identificeert als de duidelijkste open-source-hiaten en V behandelt als een workflow die nog steeds geïmplementeerd of geïntegreerd moet worden.

Referenties

• Li, J., Xiao, X., Zhang, Y., Liu, C., et al. — "Agent Harness Engineering: A Survey" (2026, ter beoordeling) — bron van de ETCLOVG-taxonomy, het driedelige kader, de synthese tussen de lagen en de open-source-ecosysteemkaart. Projectpagina · OpenReview PDF. Geparafraseerd met bronvermelding.
• HarnessFix (arXiv:2606.06324, 2026) — vervolgwerk over op traces gebaseerd harness-herstel; gebruikt laagtoewijzing in ETCLOVG-stijl als diagnostisch vocabulaire om runtime-bewijs te koppelen aan harness-mechanismen.
• TrueFoundry Agent Harness — on-demand sandbox (E), MCP-tooling (T), context-suite (C), orchestratie-loop (L) en traces (O) als gedocumenteerde functionaliteiten, met governance (G) grotendeels native en verificatie (V) als een gekoppelde workflow op de telemetrie van de runtime.
• Harness vs. scaffold, JIT context en online evaluation — de verdiepingen per laag die dit overzicht verbindt.
• AI governance and audit en OpenTelemetry at the gateway — de G- en O-lagen in detail.

Northwind en Priyanka zijn een illustratieve samenvoeging, geen specifieke organisatie of incident. De ETCLOVG-taxonomy, het driedelige kader, de cross-layer-effecten, bevindingen van de ecosysteemkaart en open problemen zijn geparafraseerd uit "Agent Harness Engineering: A Survey" (Li et al., 2026), met bronvermelding; definities van lagen volgen de projectpagina van de survey. De taxonomy is een onderzoeksvoorstel dat ter beoordeling voorligt, geen industriestandaard. De pseudocode voor de laagweergave is illustratief en is geen letterlijke TrueFoundry-productconfiguratie. Functionaliteiten van TrueFoundry weerspiegelen de openbare documentatie op het moment van schrijven; controleer dit aan de hand van de huidige documentatie.

‍