Taakspecifieke agent

Wat is een taakspecifieke agent?

Een taakspecifieke agent is een AI-agent die één job doet, waarbij de grenzen van die job vastliggen voor hij ook maar één keer draait. De taak ligt vast, de tools die hij mag aanroepen liggen vast, de data die hij mag lezen ligt vast, en er staat ergens neergeschreven wanneer een run afgewerkt is. Alles daarbuiten is zijn probleem niet.

Hij zit meestal in een toepassing en niet in een chatvenster: in de gedeelde mailbox, in de ticketwachtrij, in het ERP-scherm waar het werk toch al gebeurt. De algemene assistent ernaast aanvaardt elke vraag die je kan typen. Deze krijgt één soort vraag en levert één soort resultaat.

Die smalle scope is het volledige ontwerp. Elk van die vier grenzen is een keuze die iemand bewust gemaakt heeft, en elke keuze haalt een hele categorie fouten weg nog voor de eerste run. Een agent die enkel de orders van de klant in kwestie mag lezen, kan de prijzen van een andere klant niet doorsturen.

Leveranciers hebben die vorm in hun tooling ingebouwd. Microsoft beschrijft een declarative agent voor Microsoft 365 Copilot als iets dat op dezelfde orkestrator en dezelfde modellen draait als Copilot zelf, maar toegespitst op één zakelijke nood via drie geconfigureerde onderdelen: instructies, acties en knowledge sources.

De vier dingen die je vastlegt, en wat elk ervan wegneemt

Elk van die vier staat op zichzelf, en er eentje overslaan is precies hoe een project eindigt met een agent die niemand durft aanzetten.

Eén taak
Schrijf de job als één zin zonder "en" erin. "Beantwoord klanten die vragen wanneer hun bestelling vertrekt." Heb je een "en" nodig, dan heb je twee agents, en bouw je de eerste. Wat dat wegneemt is het gokwerk: het model moet nooit uitvissen in welk van je vijf processen het zit, want er is er maar één.

Eén set tools
De agent krijgt de tools die de taak nodig heeft en verder niets. Dat haalt twee fouten tegelijk weg. Het model kan de verkeerde tool niet kiezen uit een lijst waar die niet in staat, en een misser raakt niet verder dan waar de tools reiken. Anthropic schrijft in zijn technische stuk over het bouwen van agents dat tooldefinities evenveel ontwerpaandacht verdienen als een gebruikersinterface, met duidelijke documentatie en een voorbeeld per tool. De regel die je in de praktijk het meeste last bespaart: nooit twee tools die bijna hetzelfde doen, want net die twee gaat het model door elkaar halen.

Eén datascope
Jij bepaalt welke bronnen de agent mag lezen en met wiens rechten hij dat doet. In Copilot Studio hang je knowledge sources aan de agent, en voor SharePoint en Dataverse leest hij die met de Entra ID van de ingelogde persoon, zodat hij enkel content bovenhaalt die die persoon zelf ook mocht openen. Er is ook een instelling Allow ungrounded responses. Zet je die af, dan blokkeert de agent elk antwoord uit een beurt waarin hij noch een knowledge source noch een tool geraadpleegd heeft, en geeft hij het gesprek door aan het fallback topic in plaats van iets te verzinnen. De documentatie van Microsoft zet er zelf de eerlijke nuance bij: die schakelaar garandeert niet dat het model nooit op zijn algemene kennis steunt, hij blokkeert enkel de beurten waarin er helemaal niets geraadpleegd werd.

Een afwerkvoorwaarde
Schrijf op wat waar moet zijn voor een run als afgewerkt telt, in een vorm die iemand anders kan nakijken zonder het volledige gesprek te lezen. Er staat een draft in de mailbox en er staat een ordernummer in. Een ticket heeft een categorie en een eigenaar. Anthropic raadt stopvoorwaarden aan, zoals een maximum aantal iteraties, om een agent onder controle te houden. Dat is nuttig, maar een stapcap en een afwerkvoorwaarde zijn twee verschillende dingen. De cap stopt de run. De afwerkvoorwaarde zegt of de run gelukt is. Hoe je die goed ontwerpt, is het onderwerp van loop engineering, en het is net het stuk dat teams overslaan.

Taakspecifieke agent versus algemene assistent

Wat ze uit elkaar houdt is of je voor de run kan zeggen hoe een juist resultaat eruitziet.

• Wat je hem vraagt
  De taakagent krijgt één soort vraag in een voorspelbare vorm. De assistent krijgt alles wat je kan typen, ook dingen waar niemand op gerekend had.

• Wat juist betekent
  Bij de taakagent ligt dat per geval vast voor de run. Bij de assistent wordt het per antwoord beoordeeld achteraf, door wie het toevallig leest.

• Hoe je hem test
  De taakagent heeft een set oude gevallen met verwachte uitkomst die je na elke wijziging opnieuw draait. De assistent heeft steekproeven en klachten.

• Wie eigenaar is
  De taakagent hoort bij de proceseigenaar voor wie hij gebouwd is. De assistent helpt iedereen, dus is hij meestal van niemand, en merkt niemand het wanneer zijn antwoorden slechter worden.

De twee vullen elkaar aan. De assistent pakt de staart: de rare eenmalige vraag, het document waar geen proces voor bestaat, het ding dat twee keer per jaar gebeurt. De taakagent pakt het volume: dezelfde vraag 200 keer per week, waar de winst zit in er nooit meer over te moeten nadenken. Een bedrijf met allebei is normaal. Een bedrijf dat de assistent het volumewerk laat dragen, krijgt output die niemand kan nakijken, en een bedrijf dat voor elke staartvraag een taakagent wil bouwen, geraakt nooit voorbij de eerste.

Waarom net de begrensde agents in productie geraken

Pilots blijven steken om redenen die weinig met modelkwaliteit te maken hebben. Vier daarvan verdwijnen zodra de scope klein genoeg is om op te schrijven.

Je kan zeggen wat juist betekent. Voor één taak schrijf je het slaagcriterium in een zin, en daarmee wordt automatisch beoordelen mogelijk. Microsoft Foundry levert ingebouwde agent-evaluators, waarvan een deel nog in preview zit, die het zelf omschrijft als unit tests voor agentische systemen, met een pass of een fail per geval. Task adherence kijkt of de agent de regels en beperkingen uit zijn instructies gevolgd heeft, en tool selection of hij de juiste tools koos zonder overbodige tools te kiezen. Geen van beide vragen heeft een antwoord voor een assistent die morgen om het even wat kan krijgen.

Je kan hem testen voor en na elke wijziging. In Copilot Studio bouw je een testset van echte gevallen en kies je per geval hoe er beoordeeld wordt: betekenis vergelijken met een verwacht antwoord, een pass of fail op de vraag of de agent de verwachte tools gebruikte, of een eigen test waarin je zelf de criteria schrijft en elk resultaat een label geeft. Die set geeft je een slaagpercentage, en dat cijfer maakt van "de agent lijkt nu beter" iets dat je in een changeticket kan zetten. Het lemma evals beschrijft dezelfde discipline een niveau lager, bij de modelaanroep zelf.

Je kan er een prijs op plakken. Een bekende taak met een bekend volume geeft je kost per run maal runs per maand, en dat is een cijfer waar een financieel verantwoordelijke ja of nee op kan zeggen. Het verbruik van een algemene assistent hangt af van hoe nieuwsgierig de mensen deze week zijn. Een begrensde agent is ook de vorm waar een uitgavenlimiet voor agents echt op past, want je weet wat een normale run kost en je ziet de runs die daar niet op lijken.

Je kan een eigenaar aanduiden. De job hoort bij een proces waar al iemand verantwoordelijk voor is: de magazijnverantwoordelijke, het hoofd klantendienst, de boekhouder. Die persoon kan de output beoordelen, want vroeger maakte hij ze zelf. Het lemma agentregister gaat over hoe je dat eigenaarschap opgeschreven houdt.

Een uitgewerkt voorbeeld: de agent voor leverdatums

Vier vragen bepalen of zo'n agent werkt. Wat is die ene zin die de job beschrijft? Wat is de kleinste set tools die ze afmaakt? Wat doet hij als hij het niet zeker weet? En hoe ziet een mens achteraf wat hij gedaan heeft? Heeft je bedrijf nog geen agent in dagelijks gebruik, dan is dit de vorm om mee te beginnen, en die vier antwoorden horen op papier te staan voor er iets gebouwd wordt.

Een groothandel in bouwmaterialen krijgt een gestage stroom mails met één vraag: wanneer komt mijn bestelling? Dit is de scope, eerst opgeschreven.

• Taak
  Een antwoord in draft zetten op binnenkomende mails die naar de leverdatum van een bestaand order vragen.

• Tools
  De gedeelde verkoopmailbox lezen. Een order opzoeken op nummer of op het mailadres van de afzender. De geplande verzenddatum uit het ERP lezen. Een draft in de mailbox schrijven. Niet versturen. Geen enkel order wijzigen.

• Data
  Orders van de laatste twaalf maanden van de klant die de mail stuurde. Niets van andere klanten, geen prijstabellen, geen leverancierscontracten.

• Afwerkvoorwaarde
  Er staat een draft in de mailbox, er staat een ordernummer in, en er staat ofwel een verzenddatum in ofwel één zin dat de datum nog niet bevestigd is.

• Bij twijfel
  Geen overeenkomstig order, meer dan één plausibel order, of een vraag die niet over een leverdatum gaat: de mail verhuist naar de verkoopmailbox met één zin reden en zonder draft.

• Wat een mens ziet
  Per run: de binnengekomen mail, het order dat hij eraan koppelde, de tools die hij aanriep en de draft die hij schreef, in een lijst die de verkoopverantwoordelijke kan openen. Geen logbestand dat enkel een beheerder leest.

En dan de vraag die hij moet weigeren. Een klant antwoordt: "Goed, maar schrap lijn 3 en doe er meteen twintig zakken cement bij." De agent heeft geen enkele tool die een order wijzigt, dus hij kan niet handelen. Dat gat is bewust gelaten. Zelfs als de ERP-connector het technisch aankan, staat er in de taak dat hij een antwoord over een leverdatum opstelt, dus het juiste gedrag is de mail naar verkoop schuiven met als reden "orderwijziging gevraagd". Een perfect redelijke vraag van een klant. Alleen niet de job van deze agent.

Het rekenwerk maakt duidelijk of het de moeite is. Stel dat er zestig van die mails per week binnenkomen en dat elke mail ongeveer vier minuten met de hand kost: order zoeken, verzenddatum checken, een beleefd antwoord typen. Dat is vier uur per week. Duurt het nakijken en versturen van een klaargezette draft een minuut, dan kosten diezelfde zestig mails één uur. De drie uur die vrijkomen, zitten bij één team op één taak, dus je kan ook echt meten of ze effectief vrijgekomen zijn.

Wat een leverancier bedoelt als er agent op de pagina staat

Het meeste wat vandaag als agent in een SaaS-product verkocht wordt, is een taakspecifieke agent: een afgebakende hulp voor planning, voor het boeken van onkosten, voor eerstelijnssupport binnen de data van dat product zelf. Dat is prima, en vaak precies wat je wil. Het punt is dat het woord op de prijspagina niets zegt over wat het ding kan, dus laat het niet doorgaan voor een capaciteitsbelofte.

Salesforce publiceert zes niveaus van agentische controle voor zijn eigen platform, van een agent die zonder instructies zijn eigen acties kiest tot een hard gecodeerd script met deterministische logica. Eén leverancier, één woord, zes verschillende hoeveelheden autonomie erachter. Stel dus de concrete vragen: wat is die ene job, welke systemen raakt hij aan en met wiens rechten, wat gebeurt er als hij een geval niet aankan, en wat kost een run. Komen de antwoorden terug als bijvoeglijke naamwoorden, dan lees je marketing. Het lemma AI-washing en agent-washing heeft de langere versie van dat gesprek.

Waar moet je op letten bij een taakspecifieke agent

Scope creep is de typische fout van deze vorm. De agent doet één soort mail goed, dus vraagt iemand of hij retours er ook bij kan nemen, daarna klachten, daarna prijsaanvragen. Elke uitbreiding is klein en elke uitbreiding wordt goedgekeurd door een andere persoon in een andere week. Niemand draait de testset opnieuw, want er was nooit een moment dat als release aanvoelde. Zes maanden later beschrijft de scopezin in de configuratie nog altijd de originele job, beantwoordt de agent vier soorten mail, en kan niemand nog zeggen wat juist betekent. De regel die dat tegenhoudt: de scopezin aanpassen is een wijziging, en een wijziging betekent dat de testset opnieuw draait voor het live gaat.

Een mens die elke derde output stilletjes bijstuurt, betekent dat je afwerkvoorwaarde niet klopt. Als de proceseigenaar de meeste drafts nog aanpast voor hij ze verstuurt, levert de agent een eerste poging in plaats van een afgewerkte job. Dat kan nog altijd de moeite zijn, maar zeg het dan hardop en meet hoe vaak er bijgestuurd wordt, anders is de winst die je bij de pilot rapporteerde niet de winst die je krijgt.

Begrensd is niet hetzelfde als veilig. Een smalle agent die klantenmails leest, leest nog altijd tekst geschreven door vreemden, en instructies die daarin verstopt zitten zijn de klassieke weg voor prompt injection. De kleine set tools beperkt wat een aanvaller eruit haalt, en dat is precies waarom je die kleine set wil, maar de poging tegenhouden doet ze niet.