Koppelingen en skills

Wat een koppeling doet

Een koppeling verbindt de AI-toepassing met een andere bron of toepassing. Dat kan een zoekfunctie in een documentomgeving zijn, toegang tot een agenda of een handeling die een nieuw record maakt. De mogelijkheden zijn specifiek. ‘Verbonden met de agenda’ kan betekenen dat je afspraken kunt lezen, terwijl het maken of wijzigen van afspraken apart geregeld is.

Een API is een interface waarmee programma’s gegevens of handelingen kunnen uitwisselen. Een connector maakt zo’n verbinding bruikbaar in een bepaalde toepassing. Een webhook kan een gebeurtenis doorgeven, bijvoorbeeld wanneer een formulier is ingezonden. Je kunt deze onderdelen combineren: een webhook start het werk, een connector haalt gegevens op en een API bewaart het resultaat.

Niet iedere koppeling is live op dezelfde manier. Een zoekopdracht kan gegevens op dat moment ophalen; een kennisbron kan eerst een kopie of index gebruiken. Kijk daarom naar actualiteit als je vraag daarvan afhangt. Voor de agenda van vandaag maakt het uit wanneer de informatie voor het laatst is vernieuwd.

MCP

Model Context Protocol, meestal MCP genoemd, is een open standaard om AI-toepassingen met externe gegevens en tools te verbinden. Een toepassing kan via zo’n verbinding beschikbare functies ontdekken en gebruiken. Het is een manier om aansluitingen tussen toepassingen minder eenmalig te maken.

De standaard bepaalt niet automatisch de betekenis of kwaliteit van een tool. Een functie kan ‘zoek documenten’ heten, maar de zoekvelden, resultaten en toegang verschillen per aanbieder. Je moet nog steeds begrijpen wat er wordt gezocht: bestandsnamen, volledige tekst, een specifieke map of alleen een vooraf gemaakte verzameling.

Stel dat de AI een handleiding zoekt. Een bruikbare zoektool geeft meer terug dan alleen een stuk tekst: ook de titel, vindplaats, datum of versie kunnen nodig zijn. Als vervolgens een document wordt geopend, moet duidelijk zijn dat dit dezelfde bron is. Een goed verbonden toepassing helpt die stappen herleidbaar te houden.

Een MCP-verbinding kan bestaan zonder dat elke gewenste handeling beschikbaar is. Dat merk je bijvoorbeeld als lezen lukt maar opslaan niet. Beschrijf een ontbrekende mogelijkheid dan als een ontbrekende tool of bevoegdheid, in plaats van te verwachten dat een andere formulering van de prompt de aansluiting alsnog maakt.

Wat een skill is

Een skill bewaart kennis over een bepaald soort werk. In de Agent Skills-standaard bestaat een skill uit een map met een SKILL.md en eventueel aanvullende bestanden, zoals voorbeelden, templates of scripts. De toepassing moet die standaard ondersteunen om de skill op de bedoelde manier te gebruiken.

In het instructiebestand kun je beschrijven wanneer de skill van toepassing is, welke bronnen nodig zijn en hoe de uitkomst eruitziet. Een skill voor een weekupdate kan bijvoorbeeld uitleggen hoe acties worden opgenomen, wat een definitieve status betekent en hoe je ontbrekende informatie markeert. Een voorbeeld laat daarna zien hoe de tekst eruit moet zien.

Je hoeft niet alles in één groot bestand te zetten. Een kort begin kan verwijzen naar een template of een uitgebreidere toelichting. Dat houdt de werkwijze leesbaar en maakt het makkelijker om een specifiek onderdeel te onderhouden. Gebruik herkenbare namen en leg uit waarvoor ieder bestand bedoeld is.

weekupdate/
  SKILL.md             — wanneer en hoe deze werkwijze gebruikt wordt
  templates/update.md  — de gewenste structuur
  examples/update.md   — een fictief uitgewerkt voorbeeld
  scripts/check.py     — optionele controle op vaste velden

Dit is een voorbeeldstructuur, geen kant-en-klare geïnstalleerde skill. Een script in de map wordt ook niet vanzelf uitgevoerd. De instructie en de omgeving moeten duidelijk maken wanneer het nodig is en hoe de uitkomst van de controle wordt gebruikt.

Het verschil

Een skill geeft op zichzelf geen toegang tot bestanden. Een koppeling bepaalt op zichzelf geen schrijfstijl. Een projectcontext plant op zichzelf geen uitvoering. Als je deze rollen uit elkaar houdt, is het eenvoudiger om te begrijpen waarom een toepassing iets nog niet kan of waarom het resultaat tegenvalt.

Een servicevraag voorbereiden

Een fictieve medewerker behandelt vragen over een product. De vragen komen uit een formulier. Er is een map met actuele handleidingen en een overzicht met eerder beantwoorde vragen. Het doel is een conceptantwoord met bronverwijzingen, dat de medewerker controleert voordat er iets wordt verstuurd.

De koppeling haalt de nieuwe vraag en de relevante handleiding op. De skill beschrijft de vorm van het concept: eerst een direct antwoord, daarna de stappen en onderaan eventuele ontbrekende informatie. De projectcontext bevat de productnamen en geeft aan welke handleiding actueel is. De workflow bewaart het concept bij de vraag.

Een vraag als ‘het apparaat doet het niet’ bevat te weinig informatie voor een specifieke oplossing. De skill kan dan voorschrijven dat een verduidelijkende vraag wordt opgesteld. Een vergelijkbare eerdere vraag kan helpen, maar is geen bewijs dat dezelfde oorzaak speelt. Het concept moet daarom onderscheid maken tussen wat bekend is en wat nog uitgevraagd moet worden.

Bij een vollediger vraag kan het concept verwijzen naar een concrete paragraaf in de handleiding. De medewerker ziet dan niet alleen het voorgestelde antwoord, maar ook waarom dat antwoord past. Als de handleiding geen oplossing bevat, hoort het concept dat aan te geven. Het model hoeft het gat niet met een aannemelijke procedure op te vullen.

Vaste controles

Een deel van de kwaliteit kun je met vaste controles bewaken. Heeft het concept een bronverwijzing? Is het juiste vraagnummer opgenomen? Bestaat het bestand op de bedoelde plek? Zulke controles vragen vooral om duidelijke regels. Een klein script of een vaste workflowstap kan daarvoor geschikter zijn dan een extra vrije beoordeling door een model.

Andere controles vragen begrip. Beantwoordt de tekst werkelijk de vraag? Is de gekozen handleiding van toepassing op dit product? Daar kan AI bij helpen, maar het blijft nuttig om voorbeelden met bekende uitkomsten te bewaren. Gebruik ook gevallen waarin de juiste reactie is dat er nog geen antwoord gegeven kan worden.

Laat bij een koppeling die iets opslaat de uitkomst teruglezen. Een bevestiging dat een verzoek is ontvangen, is nog geen zichtbare concepttekst. Als teruglezen niet lukt, wil je die beperking bij het resultaat zien. Dat maakt het makkelijker om het probleem in de verbinding of in de werkwijze te vinden.

Wanneer een skill wordt gebruikt

Een skill heeft een herkenbare aanleiding nodig. Beschrijf bij welke taak de werkwijze hoort en welke informatie vooraf beschikbaar moet zijn. Bij het servicevoorbeeld kan dat zijn: een conceptantwoord maken voor een vraag over een bekend product, met toegang tot de bijbehorende handleiding. De skill begint dan met de vraag en het product vaststellen.

Geef ook een voorbeeld waarvoor deze werkwijze niet past. Een verzoek om een nieuwe serviceprocedure te ontwerpen, is iets anders dan een bestaand antwoord voorbereiden. Als de toepassing bij beide vragen automatisch dezelfde stappen volgt, krijg je misschien een antwoord in het juiste format terwijl de verkeerde taak wordt uitgevoerd.

Leg voor de passende taak vast wat ‘klaar’ betekent. Bijvoorbeeld: een concept met de relevante uitleg, verwijzingen naar de handleiding en ontbrekende informatie apart vermeld. Daarmee kan de gebruiker het eindresultaat bekijken zonder alle tussenstappen te hoeven raden. De aanleiding, benodigde invoer en gewenste uitkomst horen bij elkaar.

Bij een uitzondering kan de skill een gerichte vraag stellen of de taak teruggeven. Is het product onbekend, dan wordt eerst het product nagevraagd. Ontbreekt de handleiding, dan wordt zichtbaar welke bron nog nodig is. Zulke keuzes houden de werkwijze begrijpelijk; je hoeft niet ieder ontbrekend gegeven met een extra algemeen voorschrift op te vangen.

Bewaar een paar voorbeelden naast de skill: een gewone servicevraag, een onvolledige vraag en een vraag die buiten de taak valt. Als de omschrijving of de stappen veranderen, probeer je die voorbeelden opnieuw. Zo beoordeel je zowel het resultaat als de vraag of de skill op het juiste moment wordt gebruikt.

Bijhouden en aanpassen

Koppelingen en skills veranderen mee met het werk. Een formulier krijgt een nieuw veld, een handleiding krijgt een nieuwe versie of het team wil een andere antwoordvorm. Werk de relevante afspraak bij en probeer daarna opnieuw een paar bekende vragen. Zo zie je of een wijziging ook gevolgen heeft voor bestaande gevallen.

Bewaar bij de skill de herkomst van belangrijke regels. Een stijlvoorkeur komt bijvoorbeeld van het team, een inhoudelijke stap uit de handleiding. Als die bronnen veranderen, weet je welke regels je opnieuw moet bekijken. Het voorkomt dat een oude uitzondering ongemerkt een algemene afspraak blijft.

Je kunt klein beginnen: één bronverbinding, één herkenbare werkwijze en één plek voor het concept. Zodra die combinatie begrijpelijk werkt, kun je beter bepalen welke extra aansluiting nodig is. Meer over de uitvoering lees je bij AI-agents; voor de achtergrond bij het werk is er Projects en context.