De AI Agent Glossarium, Toegepast op Productie-Infrastructuur

Het agent-domein heeft een vocabulaireprobleem. Na een periode waarin "harness," "scaffold," "skill," en "agent" in elk gesprek iets anders betekenden, publiceerde Hugging Face een breed gedeelde begrippenlijst die de sector een nuttig werkjargon biedt. Het is het lezen waard. Maar een begrippenlijst beantwoordt de vraag "wat betekent dit woord?" — en de volgende vraag, waar platformteams dagelijks mee te maken hebben, is "waar bevindt dit ding zich in mijn stack?" Dit artikel neemt die werkwoordenschat en koppelt elke term aan het onderdeel van de productie-infrastructuur dat deze implementeert. De woorden zijn afkomstig uit een opkomend vakjargon binnen de community; de technische aansluiting is wat productieteams concreet moeten maken.

Elif, een platform engineering lead, zag hoe een stuurgroepvergadering veertig minuten verloor aan een vraag die niet meer dan vijf minuten had mogen duren: "hoeveel agents hebben we?" Engineering telde de harness-deployments en zei negen. Het datateam telde de prompts-met-tools en zei dertig-en-nog-wat. Een vendor-slide telde elke workflow met een LLM-call en zei tweehonderd. Niemand had ongelijk volgens hun eigen definitie; niemand deelde dezelfde definitie. Diezelfde vergadering struikelde over de vraag of een "skill" een tool was, of de nieuwe "sub-agent" een agent was voor inventarisatiedoeleinden, en wat het team precies kocht als een product zei "harness inbegrepen." Elif's conclusie was niet dat haar collega's slordig waren. Het was dat de terminologie in het vakgebied sneller was geëvolueerd dan het gedeelde begrip — en dat totdat de woorden gekoppeld werden aan concrete onderdelen in de stack, elk architectuurgesprek in feite een discussie over definities zou blijven.

De community werkt aan het verduidelijken van deze definities — het meest zichtbaar in Hugging Face's agent-glossarium, dat ontstond uit precies deze verwarring op ICLR 2026 en waar we in dit artikel naar verwijzen (en credits aan geven). Wat dit artikel toevoegt, is de tweede kolom die Elif nodig had: voor elke term de productiecomponent die deze implementeert, en de governance die eraan gekoppeld is zodra het echte infrastructuur wordt in plaats van een label op een diagram. Dit is geen vervanging van het Hugging Face-glossarium; het is de infrastructuurkolom ernaast. We lopen van binnen naar buiten door de stack — model, scaffold, harness, agent — en behandelen vervolgens het omliggende werkvocabulaire: context engineering, het tool/skill/sub-agent spectrum, policy en de trainingstermen die ook in productie van belang blijken te zijn. Na dit artikel volgen vier verdiepingsartikelen; dit is de overzichtskaart.

1. Model: het Kleinste Onderdeel van het Systeem

Begin waar het glossarium begint. Het model is de LLM zelf: tekst in, tekst uit, geen geheugen tussen calls, geen loop, geen mogelijkheid om daadwerkelijk iets uit te voeren. Het kan de intentie om een tool aan te roepen uitdrukken — een gestructureerd verzoek genereren — maar iets daarbuiten moet die tool uitvoeren en het resultaat terugkoppelen. Het model "de agent" noemen is de fundamentele denkfout: het model is de redeneermotor, en op zichzelf beantwoordt het één prompt en stopt het.

In termen van productie is het model ook het meest inwisselbare onderdeel — wat precies de reden is waarom het achter een abstractie moet zitten. Op TrueFoundry worden modellen bij naam aangeroepen via de enkele OpenAI-compatibele API van de AI Gateway: commerciële topmodellen, self-hosted open-weight modellen en gefinetunede checkpoints achter een gemeenschappelijke gateway-interface, met RBAC, budgetten, observabiliteit en guardrails die centraal worden toegepast waar het verkeer door de gateway stroomt. Het architectonische gevolg van "het model is slechts één component" is dat het vervangen ervan een configuratiewijziging moet zijn — het onderwerp van ons unified-API artikel — en al het andere in dit glossarium is wat op zijn plaats blijft wanneer u het vervangt.

2. Scaffold en Harness: de Twee Lagen die Iedereen Verwart

Hier is het onderscheid waarvoor het glossarium bestaat, en het onderscheid dat in de praktijk voor de meeste verwarring zorgt. De scaffold is de gedragsbepalende laag van waaruit het model werkt: de system prompt, de tool-beschrijvingen, de uitvoerformaten die het moet volgen, de regels voor wat er tussen stappen wordt doorgegeven. Het vormt de manier waarop het model zijn wereld ziet. De harness is de uitvoeringslaag die de agent laat draaien: de loop die het model aanroept, de tool-verzoeken verwerkt, ze daadwerkelijk uitvoert, resultaten terugkoppelt, fouten afhandelt en beslist wanneer te stoppen. Scaffold is instructies; harness is de machinerie. Producten zoals Claude Code gebruiken "harness" vaak losjes voor alles wat niet het model is, wat prima is als verkorte weergave — het onderscheid bewijst zijn nut wanneer u redeneert over de afzonderlijke lagen, wat in productie voortdurend gebeurt: een prompt-aanpassing is een scaffold-wijziging die u in minuten kunt doorvoeren; een wijziging aan stopcondities of foutafhandeling is een harness-wijziging met een bredere impact op het systeem.

Op TrueFoundry hebben de twee lagen twee verschillende plekken, wat op zichzelf verhelderend is. Scaffold-artefacten — instructies, prompt-versies, tool-beschrijvingen, skills — zijn beheerde content: geversioneerd, beoordeelbaar, onderhevig aan RBAC. De harness is de beheerde runtime: TrueFoundry's Agent Harness voert de plan→act→observe loop uit, voert tools uit via beheerde gateways, beheert de sandbox, dwingt goedkeuringsstappen af en legt de stappen van beheerde Agent Harness-runs vast. U stelt de scaffold samen; het platform beheert de harness. De verdieping die op dit artikel volgt, gaat volledig over die scheiding en de discipline die de community nu harness engineering noemt.

3. Agent: de Formule en Wat het U Oplevert

Nu deze twee lagen benoemd zijn, is een agent niet langer mysterieus: een agent is een model plus alles eromheen dat het in staat stelt te handelen in plaats van alleen te reageren — het kader dat de community samenvat als agent = model + harness. De oorsprong ligt bij reinforcement learning, waar een agent simpelweg het onderdeel is dat observaties verwerkt en acties retourneert in een loop; de LLM-variant behoudt die loop en vult de "beslis"-stap in met een model. Uit deze formule volgen twee praktische consequenties die belangrijk zijn om te begrijpen.

Ten eerste: wat gebruikers ervaren als een "agent-product" is vaak de harness en scaffold rondom het model. Wanneer twee producten die op hetzelfde onderliggende model zijn gebouwd compleet anders aanvoelen, zit het verschil in de harness en scaffold — het ontwerp van hun loop, hun contextbeheer, hun toolsets. Het model, de harness en het product zijn drie verschillende dingen, en het beoordelen van "een agent" zonder te specificeren in welke harness deze draaide, is vrijwel betekenisloos. Ten tweede wordt inventarisatie mogelijk. Elif's vraag "hoeveel agents hebben we?" heeft een antwoord zodra een agent een concreet, geregistreerd object is: een definitie (model + scaffold + tool-rechten) plus een runtime. Voor agents die via TrueFoundry’s Agent Harness draaien, wordt de agent een geregistreerde definitie die op naam verwijst naar een model, MCP-servers en skills, waarbij credentials in de gateway-laag worden bewaard in plaats van in de definitie zelf. Dit maakt het beheerde agent-landschap meetbaar en auditeerbaar in plaats van een discussie over begrippen.

Een agent-definitie, geannoteerd met de begrippen uit het glossarium (illustratief)

Wanneer u afstand neemt van de runtime, valt het hele vocabulaire op dezelfde manier op zijn plek: elke term aan de linkerkant is een concept, en elke term heeft een concrete productieomgeving aan de rechterkant.

4. Context Engineering en de Twee Geheugens

Context engineering is de discipline die bepaalt wat het model bij elke stap ziet: welke instructies, welke tool-beschrijvingen, welk deel van de historie, welke opgehaalde feiten. Het is geen eenmalige prompt-beslissing, want in een agent is de context dynamisch — de uitvoer van elke iteratie vormt de invoer van de volgende iteratie, en een harness die die opbouw niet actief beheert, ziet de prestaties van de agent verslechteren naarmate het contextvenster volloopt. Het glossarium maakt een helder onderscheid qua geheugen: kortetermiergeheugen is wat in het venster blijft tijdens een run; langetermiergeheugen blijft sessieoverstijgend extern bewaard en wordt opgehaald wanneer dat relevant is.

In productie is dit de verantwoordelijkheid van de harness, niet van de prompt-auteur — geen mens kan handmatig de context van een run met 40 stappen beheren. TrueFoundry's Agent Harness bevat een context-engineering suite die dit automatisch verzorgt: compactie vat een lange transcriptie samen en gaat door; offloading van grote resultaten houdt een omvangrijke tool-respons buiten het venster en laadt deze op verzoek; code mode stelt de agent in staat grote hoeveelheden data via code te verwerken in plaats van deze volledig in de context te lezen; sub-agents (volgende sectie) isoleren subtaken in schone contextvensters. We behandelen het probleem dat dit voorkomt — in de community bekend als context rot — in een apart artikel; hier gaat het om de koppeling: "context engineering" staat voor werk dat een beheerde runtime automatisch voor u uitvoert.

5. Tool, Skill, Sub-agent: het Delegatiespectrum

De meest praktische verheldering uit het glossarium is het onderscheid tussen drie zaken die er op het eerste gezicht allemaal uitzien als "de agent die iets uitvoert." Een tool is een actie: een enkele functie-call — voer dit commando uit, bevraag deze API — uitgevoerd door de harness en teruggekoppeld. Een skill is verpakte kennis: een herbruikbare, gestructureerde procedure voor een meerstapsdoel ("onderzoek de bug, vorm een hypothese, schrijf de fix"), die op verzoek in de context wordt geladen in plaats van als één call te worden uitgevoerd. Een sub-agent is een redeneer-gelegeerde: een agent die wordt aangeroepen door een andere agent, met een eigen model, scaffold en context, die de subtaak zelfstandig uitvoert en een resultaat retourneert. De grens kan per framework verschillen — wat het glossarium ook eerlijk erkent — maar het spectrum zelf staat vast: actie, procedure, gelegeerde.

Het belang van dit onderscheid in productie ligt in het feit dat elke trede een andere vorm van governance vereist. Een tool vereist authenticatie en autorisatie per call — wat wordt geboden door de MCP Gateway: een registry, centrale auth, RBAC per tool, en guardrails voor en na de call. Een skill vereist versiebepaling en herkomst — wie heeft deze procedure geschreven, welke versie gebruikt een agent — wat wordt geboden door TrueFoundry's Skills Registry: geversioneerde SKILL.md-artefacten met RBAC, geladen wanneer nodig. Een sub-agent heeft een eigen identiteit en een afgebakende context nodig — een eigen trace, eigen permissies, isolatie van het contextvenster van de parent — wat de Agent Harness van nature ondersteunt. Als u dit spectrum platslaat tot enkel "tools", gaat u een redeneer-gelegeerde beheren als een simpele functie-call; het verdiepingsartikel over dit spectrum ontleedt elke trede afzonderlijk.

6. Policy: Gedrag Bevindt Zich Niet Alleen in de Weights

Policy is een van de meer subtiele termen uit het glossarium, maar voor beheerteams misschien wel de belangrijkste. Afkomstig uit RL is een policy het gedrag zelf — wat het systeem in elke situatie zal doen. De cruciale conclusie is dat bij LLM-agents slechts een deel van de policy in de model-weights zit: de rest wordt bepaald door de scaffold en de harness. Hetzelfde checkpoint achter een andere system prompt, andere tool-beschrijvingen of een andere loop is qua gedrag een andere policy. Een policy is geen agent — de policy is het gedrag; de agent is het uitgerolde systeem dat dit gedrag vertoont.

Als u dit principe toepast, verdwijnt een veelvoorkomende gewoonte: het bijhouden van "welke modelversie in productie draait" alsof dat de vraag "wat gaat het systeem doen?" beantwoordt. Het beantwoordt slechts een derde van die vraag. De vertaalslag van "policy" naar productie houdt in dat de volledige gedragsbepalende stack — modelnaam, prompts, toolsets en hun beschrijvingen, skills, harness-configuratie — als één geversioneerde eenheid wordt beheerd, gecontroleerd wordt gewijzigd en integraal wordt getest op regressie. Een aanpassing van één regel in een prompt is immers net zo goed een policy-wijziging als het vervangen van het model. Dat is de stelling van het vierde artikel in deze reeks; de infrastructuur die dit beheersbaar maakt bestaat uit definities-als-artefacten (de declaratieve agent-definitie van de Agent Harness), prompt-versiebeheer en de online evaluatie-loop die gedragsveranderingen opmerkt, ongeacht in welke laag ze ontstaan.

7. De Trainingstermen die Belangrijk Blijven: Rollout en Reward

Het laatste gedeelte van het glossarium behandelt RL-trainingstermen — environment, trainer, rollout, reward — en het is verleidelijk voor een productieteam om dit over te slaan. Doe dat niet, want twee van die termen beschrijven zaken die u al gebruikt. Een rollout is één volledige agent-run, van begin tot eind: wat de agent zag, wat het deed, wat het resultaat was, stap voor stap. Productieteams noemen dat een trace. Een reward is de score die aangeeft of een run goed was — verifieerbaar (tests slagen, antwoord komt overeen) of aangeleerd (voorkeuren, LLM-as-a-judge). Productieteams noemen dat een eval-signaal. De trainingspipeline en de productie-loop hebben dezelfde structuur; de ene werkt weights bij en de andere werkt dashboards bij.

Het gevolg is belangrijk om bij stil te staan: als uw harness volledige traces per stap vastlegt en uw evaluatielaag deze beoordeelt, verzamelt u al het basismateriaal voor rollout/reward-datasets — traces plus kwaliteitssignalen die gebruikt kunnen worden voor fine-tuning of RL-gebaseerde verbeteringen. Teams die open-weight modellen in eigen beheer draaien (ons self-hosting artikel) kunnen die cirkel gericht sluiten: traces uit de Agent Harness, scores uit de evaluatielaag, fine-tuning op TrueFoundry, en het verbeterde checkpoint uitgerold achter dezelfde gateway-naam. Het laatste artikel in deze reeks behandelt deze cyclus volledig. De les qua terminologie is eenvoudig: "rollout" en "reward" zijn geen vakjargon van een ander team — het is uw eigen observabiliteit, bekeken vanuit een trainingsperspectief.

8. Waarom een Gedeeld Vocabulaire een Architectuurbeslissing Is

Elif's vergadering van veertig minuten ging niet verloren door een gebrek aan kennis, maar door ambiguïteit. Ambiguïteit in terminologie leidt tot ambiguïteit in systemen. Wanneer "agent" geen vastomlijnde betekenis heeft, kan er geen accurate agent-inventarisatie bestaan. Wanneer "harness" zowel een product, een loop, als alles-behalve-het-model kan betekenen, worden buy-versus-build-discussies over harnesses onoverzichtelijk. Wanneer de grens tussen "skill" en "tool" vervaagt, vervaagt het governance-model mee — en niet-gecontroleerde functionaliteiten zijn precies de oorzaak van wildgroei en schaduw-agents. Het vastleggen van de begrippen is de eerste stap naar het vastleggen van de architectuur.

De koppeling die dit artikel toevoegt, is de vervolgstap: elke term moet een duidelijke plek hebben. Op TrueFoundry is dat zo — modellen achter de AI Gateway, tools achter de MCP Gateway, skills in de Skills Registry, de loop en sub-agents in de Agent Harness, context engineering als onderdeel van de harness, policy als geversioneerd geheel, en rollouts als traces die de evaluatie voeden. Niets daarvan vereist specifiek TrueFoundry; het vereist een concreet antwoord op de vraag "waar bevindt deze term zich in het systeem, en wie beheert het daar." De vier opeenvolgende artikelen behandelen de belangrijkste begrippen afzonderlijk: harness versus scaffold, het tool/skill/sub-agent spectrum, policy als het element dat u feitelijk geversioneerd beheert, en de rollout-to-reward cyclus in productie.

9. Veelgestelde Vragen

Is "agent = model + harness" de officiële definitie? Er is geen officieel orgaan, en het glossarium geeft zelf aan dat veel termen geen universeel geaccepteerde definitie hebben — verschillende frameworks gebruiken dezelfde woorden daadwerkelijk anders. Het kan beter worden gezien als een nuttig en bruikbaar werkmodel: het scheidt de redeneermotor van de machinerie die actie mogelijk maakt, wat precies de scheiding is die een productie-architectuur nodig heeft. Zie het als een werkmodel en verwacht verdere verfijning in het vakgebied.

Waar eindigt de scaffold en begint de harness? De meest duidelijke scheidslijn: scaffold is waar vanuit het model werkt (prompts, tool-beschrijvingen, formaten — content); harness is wat de agent laat draaien (de loop, uitvoering, foutafhandeling, stoppen — machinerie). Producten gebruiken vaak "harness" voor beide, wat prima is totdat u de ene wilt wijzigen zonder de andere aan te raken. In de praktijk is het ook een scheiding in eigenaarschap: auteurs beheren de scaffold; het platform beheert de harness.

Is een sub-agent vanuit het perspectief van de caller niet gewoon een tool? Mechanisch wordt het vaak zo aangeroepen, waardoor de termen door elkaar gaan lopen. Het verschil zit in wat er aan de andere kant gebeurt: een tool voert een functie uit; een sub-agent redeneert — het heeft een eigen model, scaffold, context en mogelijk eigen tools. Dat verschil is onzichtbaar voor de aanroepende code, maar essentieel voor governance: een sub-agent heeft een eigen identiteit, permissies en tracing nodig, niet alleen een vermelding in de tool-lijst van de parent.

Hebben productieteams de RL-termen echt nodig? Twee ervan wel. In productietermen ziet een rollout eruit als een trace en een reward als een eval-score — terminologie voor zaken die u al produceert. Het begrijpen van het trainingskader wordt van belang op het moment dat u wilt dat agents leren van hun eigen historie: volledige traces plus kwaliteitsscores zijn de grondstoffen hiervoor.

Verandert het standaardiseren van vocabulaire daadwerkelijk iets op technisch vlak? Indirect, maar substantieel. Gedeelde begrippen maken de inventarisatie meetbaar ("agent" = geregistreerde definitie + runtime), maken vergelijkingen bij inkoop helder (elke "harness inbegrepen"-claim valt te ontleden in loop, sandbox, goedkeuringen en traces) en maken governance toewijsbaar (elke term heeft een duidelijke plek en eigenaar). Elif's probleem in de vergadering was een systeemprobleem dat leek op een semantisch probleem — dat is meestal het geval.

Een glossarium is de legenda van een kaart; dit artikel heeft geprobeerd de kaart zelf te tekenen. Het vocabulaire van de community — model, scaffold, harness, agent, skill, sub-agent, policy, rollout, reward — blijkt een productie-architectuur verrassend goed te beschrijven, term voor term, mits elke term een vaste plek krijgt. Wijs die plek toe, en de discussie verschuift van de betekenis van woorden naar het ontwerp van het systeem.

Referenties

• Hugging Face — "Harness, Scaffold, and the AI Agent Terms Worth Getting Right" (mei 2026) — het glossarium dat in dit artikel naar infrastructuur is vertaald; definities zijn geparafraseerd met bronvermelding.
• TrueFoundry Agent Harness — beheerde loop, sandbox, goedkeuringen, context-engineering suite, sub-agents, traces.
• TrueFoundry AI Gateway en MCP Gateway — waar respectievelijk modellen en tools zich bevinden.
• What is an agent harness? — de verdieping op productniveau die aansluit bij dit artikel.
• Online evaluation at the gateway — de productie "reward"-laag.

Elif is een illustratief personage en vertegenwoordigt geen specifieke persoon, organisatie of gebeurtenis. Definities in dit artikel zijn geparafraseerd uit en toegeschreven aan Hugging Face's agent-glossarium (mei 2026) en de bredere discussie binnen de community; het glossarium zelf merkt op dat veel termen geen universeel geaccepteerde definities hebben en dat het gebruik per framework verschilt. Verwijzingen naar TrueFoundry-functionaliteiten zijn gebaseerd op de openbare documentatie op het moment van schrijven; controleer de huidige documentatie voor specifieke details.

‍