Agent Skills zijn geen prompttruc — ze zijn een nieuw IV-artefact tussen proces, kennis en code

De whitepaper over Agent Skills beschrijft geen prompttruc. Ze beschrijft een verschuiving in enterprise-informatievoorziening: procedurele bedrijfskennis wordt een beheersbaar softwareachtig artefact.

De oppervlakkige lezing is: "Agent Skills zijn handige markdown-mapjes met instructies voor AI-agents." De diepere these is: Agent Skills externaliseren procedurele bedrijfskennis in kleine, versioneerbare, testbare en runtime-laadbare capability modules. In enterprise-IV termen is een Skill geen promptcomponent, maar een nieuw type IV-artefact tussen businessproces, applicatieservice, kennismanagement, automation script en governance-control in.

De architectural primitive: progressive disclosure als context governance

De technische innovatie is progressive disclosure. Metadata met naam en description zit permanent in de agentcontext. De SKILL.md body wordt pas geladen wanneer de Skill triggert. Extra resources worden alleen geladen als de Skill ze nodig heeft, en scripts kunnen deterministisch werk doen zonder de token window te vervuilen.

Dit is niet alleen een performance-optimalisatie. Het is information minimization by architecture. Dat past direct bij IV-principes zoals dataminimalisatie, need-to-know, least privilege en context partitioning. Een agent moet niet standaard alle beleidsregels, tools, klantcontext, technische instructies en procesvarianten zien. Hij moet precies genoeg context krijgen om de taak correct en controleerbaar uit te voeren.

De whitepaper stelt expliciet dat capaciteit de verkeerde metric is: actieve context is een budget, geen vat. Grotere contextwindows produceren niet automatisch betere prestaties, omdat relevante informatie verdrinkt tussen distractors. Een Skill-library met alleen metadata en de actieve skill-body in context is token-economisch fundamenteel efficiënter dan één gigantische prompt.

De vier fricties die Skills oplossen

Het document positioneert Agent Skills als antwoord op vier fricties:

1. Contextrot, te veel instructies in de prompt maken het model blind voor wat relevant is
2. Gebrek aan procedureel geheugen, LLMs hebben geen ingebouwd mechanisme om "hoe te handelen" te onthouden
3. Multi-agent overengineering, voor elke procesvariant een aparte agent bouwen is architecturaal overkill
4. Portabiliteit, procedurele kennis moet werken over verschillende agentruntimes

Het antwoord is een heldere architectural primitive: een Skill is een folder met minimaal een SKILL.md, optioneel uitgebreid met scripts/, references/ en assets/. Metadata is altijd beschikbaar, de body wordt pas bij trigger geladen, en ondersteunende resources alleen waar nodig.

Skills versus MCP, AGENTS.md, RAG, workflow engines en multi-agent

De whitepaper maakt een belangrijk onderscheid dat enterprise-IV-waardig is:

Mechanisme	Primair doel	Niet gebruiken voor
AGENTS.md	Globale projectcontext	Lange procedures, procesvarianten
Skill	Procedurele taakuitvoering	Systeemtoegang op zichzelf
MCP/tooling	Systeemintegratie	Beslislogica of beleid
RAG	Informatie ophalen	Stabiele workflowlogica
Workflow engine	Deterministische procesuitvoering	Interpretatieve dialogen
Rules engine	Formele beslisregels	Ambigue, tekstuele probleemoplossing
Fine-tuning	Gedrags- of domeinbias in model	Vers beleid of auditbare procedures
Multi-agent	Gescheiden rollen of parallelisme	Simpele procesvarianten

De whitepaper gebruikt een logistiek voorbeeld met 100 procesvarianten en concludeert dat "één agent, 100 skills" vaak eleganter is dan 100 subagents, één gigantische prompt of RAG over runbooks. Dat is plausibel bij sterke activeringscues zoals SKU, origin, weight, hazmat flag en SLA.

Maar enterprise-IV moet daar een randvoorwaarde aan toevoegen: zodra procesvarianten verschillende autorisaties, dataklassen, systeemrechten of aansprakelijkheden hebben, is een Skill-library alleen niet genoeg. Dan heb je capability profiles, policy enforcement en soms alsnog aparte agent- of runtime-boundaries nodig.

Architectuurregel: gebruik Skills voor variatie in procedure, gebruik aparte agents of runtimes voor variatie in trust boundary.

De description als routinginterface: het zwakste en belangrijkste contract

De whitepaper zegt dat de description in de YAML frontmatter de routing algorithm is. Dat is een sterke, maar riskante formulering. In klassieke software is een interface deterministisch: een API-contract zegt wat er gebeurt bij welke input. Bij Skills is de description een natuurlijke-taal-classifier die het model gebruikt om te beslissen of de Skill geladen wordt.

De interface is niet formeel, maar probabilistisch. De failure modes zijn subtieler dan HTTP 400 of 500: de juiste Skill triggert niet, de verkeerde Skill triggert, twee Skills concurreren semantisch, of een Skill triggert wel correct maar laadt te veel of onjuiste procedurele context.

Voor enterprise-IV betekent dit: een Skill description moet worden behandeld als een semantisch interfacecontract met minimaal:

• Positieve triggers: welke intenties activeren de Skill
• Negatieve triggers: welke intenties mogen hem expliciet niet activeren
• Adjacent skills: met welke Skills kan overlap optreden
• Data- en toolscope: welke informatie en tools mag de Skill raken
• Risicotier: read, draft of act
• Testset: positieve, negatieve en rephrasing cases
• Owner: domeineigenaar plus technische eigenaar

De whitepaper adviseert drie positieve en drie negatieve triggers en stelt dat 90% trigger accuracy de norm is. Voor gereguleerde omgevingen is dat onvoldoende: je moet triggerkwaliteit meten als precision, recall, false positive rate, false negative rate en collision rate met aangrenzende Skills.

Evaluatie: de vier failure modes

Het evaluatiehoofdstuk onderscheidt vier failure modes:

1. Trigger failure, de verkeerde Skill wordt geladen, of de juiste niet
2. Execution failure, de output is inhoudelijk onjuist
3. Token budget failure, de Skill body is te groot en verdringt andere context
4. Regression, een nieuwe Skill breekt bestaande Skills

De whitepaper waarschuwt voor de "evaluation illusion": je evalueert niet alleen de Skill, maar het samengestelde systeem van agent plus Skill plus tools plus context. Een Skill die alleen goed werkt, kan falen wanneer 5 tot 15 Skills tegelijk geladen zijn. Een body boven 5.000 tokens kan onder co-load contextrot veroorzaken.

Final-output-only scoring kan 20 tot 40 procent meer cases laten slagen dan trajectory-aware scoring. In read-only situaties kan een verkeerd pad met goed eindantwoord soms acceptabel zijn. Bij action-allowed workflows is dat onacceptabel: de verkeerde toolroute kan ongewenste neveneffecten veroorzaken, zelfs wanneer het eindantwoord netjes klinkt.

Voor enterprise-IV geldt: output correctness is necessary but insufficient. Tool trajectory is the control surface.

De whitepaper introduceert Evaluation-Driven Development: schrijf eerst JSON-evalcases met input, expected tools en expected output, en ontwerp daarna de Skill. De evalcase wordt bewijs, niet alleen dat iets werkt, maar ook wat de organisatie dacht dat "correct" betekende op het moment van vrijgave.

Security: Skills zijn executable supply-chain artefacts

De whitepaper zegt terecht dat Skills als dependencies moeten worden behandeld: versioneren, pinnen, reviewen in PR's, testen. Maar het document werkt security niet diep genoeg uit.

Vanuit enterprise security moet een Skill worden beschouwd als een uitvoerbaar supply-chain component met vier aanvalsvlakken:

Aanvalsvlak	Voorbeeld	Mitigatie
Promptlaag	Malafide instructies in SKILL.md of references/	Signed Skills, review, instruction/content separation
Codelaag	Kwaadaardige scripts in scripts/	SAST, dependency scanning, sandboxing, no network by default
Toollaag	Skill probeert brede tools te gebruiken	Tool allowlist, OAuth scopes, policy broker
Datalaag	Skill lekt PII of vertrouwelijke data via output	DLP, classification, output filtering, redaction

De allowed-tools in de SKILL.md template is optioneel. Voor enterprise is dat onacceptabel. allowed-tools moet verplicht zijn, en moet runtime-afgedwongen worden door de orchestrator of tool broker, niet alleen declaratief in YAML staan.

Een enterprise Skill manifest moet minimaal bevatten: Skill ID en versie, business capability, owner en approver, data classification, allowed tools, allowed data domains, OAuth/OIDC scopes, runtime sandbox profile, risk tier, eval suite hash, signature/provenance, en expiry/review date.

Een Skill zonder manifest, signature, owner, tests en tool policy is geen enterprise asset, maar een unmanaged automation risk.

Identity en Zero Trust: de Skill mag geen impliciete autoriteit krijgen

In veel agentarchitecturen ontstaat een gevaarlijk patroon: de agent heeft toegang tot tools, de Skill zegt wat te doen, en het systeem voert uit. Vanuit Zero Trust is dat verkeerd. Autorisatie moet niet impliciet volgen uit Skill-activatie.

Een volwassen IV-architectuur vraagt om contextuele autorisatie bij elke stap: wie is de gebruiker, in welk kanaal, welke Skill is geactiveerd, welke tool wordt gevraagd, welke data wordt geraakt, is de actie read/draft/act, is menselijke goedkeuring nodig, is de tool trajectory toegestaan, is de output veilig voor dit kanaal?

Voor OAuth2/OIDC: korte tokenlevensduur, minimale scopes, audience validation, token exchange per tool waar mogelijk, gescheiden service identities per capability, geen secrets in Skills, en step-up approval bij action-allowed workflows. De Skill mag nooit zelf credentialhouder zijn.

Context Debt: de nieuwe technische schuld in AI-IV

Het document introduceert "Context Debt": auteurs proberen deterministisch gedrag af te dwingen door Skill descriptions vol te stoppen met regels zoals "ALWAYS DO X". Modellen negeren zulke muren van instructie uiteindelijk, zoals ontwikkelaars wall-of-warning documentatie negeren.

De remedie is "Write Software, Not Rules" en "Shift Intelligence Left": verplaats deterministische logica naar scripts of gates. Context Debt is niet alleen technisch, maar bestuurlijk. Het ontstaat wanneer organisaties policy, proceslogica en uitzonderingen in natuurlijke taal blijven opstapelen omdat ze geen formele control layer hebben.

Een Skill-library moet niet alleen groeien. Hij moet worden ontvet, geformaliseerd en opgeschoond. Anders ontstaat een nieuwe legacy-laag: prompt legacy.

Operating model: hoe je dit enterprise-waardig organiseert

Een volwassen Skill operating model heeft vijf functies:

Functie	Verantwoordelijkheid
Skill Product Owner	Businessdoel, scope, risicotier, domeinjuistheid
Skill Engineer	Structuur, scripts, tests, packaging
AI Platform Team	Runtime, registry, CI/CD, observability
Security & Privacy	Threat model, data classification, tool policy, DPIA
Architecture Board	Standaarden, hergebruik, portfolio, lifecycle

Daaronder hoort een lifecycle: intake → classificatie → authoring → evaluation design → build → security review → CI/CD → release → runtime monitoring → periodieke review.

Het belangrijkste organisatorische inzicht: de AI-afdeling moet niet eigenaar worden van alle Skills. Domeinteams moeten eigenaar zijn van domeinlogica, terwijl het platformteam de guardrails, tooling, registry en evaluatie-infrastructuur levert. De whitepaper zegt dit expliciet: de juiste teams moeten de juiste Skills bezitten, en het AI-team mag geen bottleneck worden voor organisatiedomeinkennis.

De read/draft/act governance-ladder

De whitepaper past een read/draft/act-ladder toe die voor enterprise-IV als formele policy kan dienen:

Tier	Toegestaan	Controls
Read	Ophalen, samenvatten, analyseren	Data classification, logging, no mutation
Draft	Concepten maken, voorstellen doen	Human review, format owner, no send/commit
Assisted act	Actie klaarzetten, mens bevestigt	Approval workflow, SoD, transaction preview
Action	Beperkte mutatie uitvoeren	Policy broker, strong auth, exact trajectory, rollback
Autonomous act	Alleen voor laag risico, hoog bewijs	Continuous monitoring, compensating controls

Voor gereguleerde enterprise-omgevingen: gebruik bijna nooit direct "action-allowed" als eerste productiestap. Introduceer eerst "assisted act", waarbij de agent transacties voorbereidt maar niet commit zonder expliciete menselijke goedkeuring en controleerbare preview.

De strategische conclusie

De whitepaper stelt dat de expertise in de Skills zit, niet in de runtime. De runtime commoditiseert, de Skill-library wordt het duurzame asset. In enterprise-IV is dit een verschuiving van "applicatielandschap" naar "capability landscape". De onderscheidende waarde zit niet in ChatGPT, Gemini, Claude of een specifieke orchestrator, maar in de gecontroleerde representatie van hoe de organisatie werkt.

Voor C-levels betekent dit: business capabilities worden operationaliseerbaar op taakniveau, tacit knowledge van experts wordt een versioned artefact, Skills worden beheerbare portfolio-items, de runtime kan wisselen terwijl de Skill-library portable blijft, en niet het model maar de gecureerde expertise-library is moeilijk kopieerbaar.

De juiste conclusie is niet "we moeten Agent Skills gebruiken." De juiste conclusie is: bouw een governed procedural capability layer. Gebruik Agent Skills als formaat, maar voeg enterprise controls toe: registry, ownership, risk tiering, policy enforcement, identity scoping, secure SDLC, evals, observability, audit en lifecycle management.

Zonder die laag krijg je contextrot, toolmisbruik, shadow automation en niet-auditbare besluitvorming. Met die laag kunnen Skills een serieuze bouwsteen worden voor veilige, schaalbare en domeinspecifieke AI-adoptie in de informatievoorziening.

---

Dit artikel is gebaseerd op de Agent Skills whitepaper (Agent Skills_Day_3.pdf) en een enterprise-IV architectuuranalyse. Lees ook: SkillOpt, de paper die agent skills trainbaar maakt, SkillSpector, NVIDIA's security scanner voor skills, Microsoft Security Skills, en de Auditable AI Stack.