|
Doel |
Stel uzelf de vraag: "Welk resultaat probeer ik te bereiken?Niet: "Welke tools heb ik nodig?", "Welke connectors moet ik aanroepen?", of "Welk onderwerp moet ik ontwikkelen?"
Beschrijf duidelijk waarom de agent moet bestaan, wat hij moet bereiken en wie de doelgroep is. Focus op resultaten. Laat het ontwerp van de agent voortvloeien uit het probleem.
Verduidelijk :- Het probleem of de waardekloof
- Doelgebruikers
- De verwachte impact
- Hoe succes eruitziet
Gebruik een Jobs-To-Be-Done-structuur:
-
Als een<gebruiker>
-
Ik moet<wat er gedaan moet worden>
-
Zodat<uitkomst>
|
-
Als eennieuwe medewerker, moet ikmijn lokale HR-beleid begrijpenzodatik door het onboardingproces kan navigeren vol vertrouwen.
-
Als IT-supportmanager moet ik supportmails automatisch verwerken, zodat handmatige triage wordt verminderd.
|
- Beginnen met functionaliteiten in plaats van resultaten.
- Ontwerpen voor randgevallen.
- Meetbare succescriteria overslaan.
|
|
Triggers |
Een agenttrigger is de specifieke gebeurtenis, voorwaarde of input die een agent ertoe zet om met zijn werk of taak te beginnen. Een menselijke actie of een geautomatiseerde gebeurtenis kan de trigger initiëren.
Meer informatie: Vind de trigger die bij uw gebeurtenis past. |
- Een gebruikersbericht in de chat.
- Een nieuwe e-mail in een gedeelde inbox.
- Een nieuw record in een systeem.
- Een geplande of terugkerende taak.
|
- Autonome agenten vereisen expliciete triggers. Zonder triggers werkt de agent niet.
- De trigger is afhankelijk van onvoorspelbaar gebruikersgedrag, bijvoorbeeld door te vertrouwen op het typen van een specifiek trefwoord of zin door de gebruiker.
- De trigger mist de vereiste context, bijvoorbeeld de agent. Start wel, maar beschikt niet over voldoende metadata (record-ID, gebruikersidentiteit) om effectief te kunnen handelen.
- Triggers worden vaker geactiveerd dan het scenario daadwerkelijk vereist, wat leidt tot onnodige uitvoeringen en resourceverbruik.
- Het triggerontwerp houdt geen rekening met platformquota of -limieten, waardoor agenten de gebruikslimieten bereiken of onder belasting falen.
|
|
Hulpprogramma's en integraties |
Definieer welke acties de agent moet kunnen uitvoeren, niet alleen wat hij weet.
Tools stellen de agent in staat om gegevens op te halen of bij te werken, API's aan te roepen, workflows te activeren, berichten te verzenden en transactionele bewerkingen uit te voeren. Geef een lijst van de systemen waarvan de agent afhankelijk is en hun beperkingen (API's, authenticatiemodellen, snelheidslimieten en eigendoms-/SLA-grenzen).
Overweeg de verwachte output, succes- en kwaliteitscriteria, terugval- en foutgedrag. Afhankelijkheden bepalen vaak de haalbaarheid – pak ze vroegtijdig aan.
Meer informatie: Mechanismen voor het toevoegen van tools aan agenten. |
- ServiceNow-connector → ticketdetails ophalen
- Microsoft Entra ID-connector → gebruiker ophalen Locatie
- Jira API → werkitems bijwerken
- Outlook-connector → e-mail beantwoorden
|
- Geen logboekregistratie van acties of opslag van uitvoer voor auditdoeleinden.
- Er wordt vanuit gegaan dat API's stabiel en altijd beschikbaar zijn.
- Hulpmiddelen voor het overschrijden van machtigingen.
- Geen fallback-gedrag gedefinieerd voor toolaanroepen (geen validatie van tooluitvoer, geen fallback bij fouten in tools, geen escalatiepad).
- Snelheidslimieten of throttling genegeerd.
- Ontbrekende afhankelijkheidsmapping (wie is de eigenaar van elke API, wat is de service level agreement?).
- Geen validatie van voorwaarden voordat acties worden uitgevoerd.
|
|
Kanalen |
Een kanaal is het specifieke platform of de interface waarop uw agent is geïmplementeerd en interactie heeft met gebruikers.
Het kanaal beïnvloedt ook de verwachtingen van gebruikers met betrekking tot latentie, beurtwisseling en de algehele ervaring. |
- Microsoft Teams
- SharePoint
- Microsoft 365 Copilot
- Webchat- of spraakinterfaces
|
- Kanalen kiezen op basis van gemak of eenvoud van implementatie, in plaats van op basis van hoe en waar gebruikers daadwerkelijk werken.
- Aangenomen dat gebruikers zich aanpassen aan het kanaal van de agent in plaats van gebruikers te ontmoeten waar deze al zijn.
- Prioriteit geven aan technische haalbaarheid boven gebruikerservaring, wat resulteert in een lage acceptatie, zelfs als de agent correct werkt.
- 'chat-first' ontwerpen wanneer het echte kanaal e-mail- of werkstroomgestuurd is (een gespreksgerichte gebruikerservaring creëren terwijl de ondersteuning eigenlijk plaatsvindt via Outlook; vergeten dat e-mail beurtelings is en niet conversationeel)
- Kanaalspecifieke beperkingen negeren (Outlook vereist volledige antwoorden, geen verduidelijkende vragen; Teams ondersteunt adaptieve kaarten, e-mail niet)
|
|
Kennis en gegevens |
Documenteer de informatie die de agent nodig heeft om te redeneren en de locatie waar de kennis of gegevens momenteel beschikbaar zijn. Denk aan de kwaliteit en recentheid van gegevens, gestructureerde versus ongestructureerde inhoud, en toegangs- en toestemmingsgrenzen.
Als u niet vroeg genoeg begint met het voorbereiden van uw gegevens, kan dat in een later stadium voor problemen zorgen. |
- Documenten
- Databases
- Websites
- Knowledge Base
- Interne of externe systemen
|
- Slecht of inconsistent gegevensbeheer. Wanneer eigendom, vernieuwingsfrequentie en updateprocessen niet zijn gedefinieerd, raken gegevens snel verouderd of tegenstrijdig.
- 'Documenten' verwarren met 'kennis'. Wijzen naar grote documentopslagplaatsen als bron van waarheid, zonder na te gaan of die documenten actueel, goed gestructureerd of consistent gelabeld zijn.
- Kennisbronnen spreken elkaar tegen. Meerdere versies van een beleid, procedure of gegevensset leiden de agent naar conflicterende instructies.
- Machtigingen en toegangscontroles zijn niet expliciet ontworpen. Gevoelige inhoud wordt onbedoeld openbaar gemaakt, of de agent verwijst naar kennis waartoe eindgebruikers geen toegang hebben.
- Het uitbreiden van kennisbronnen zonder de beveiligingsgrenzen te valideren, wat resulteert in agenten die te veel delen of falen wanneer de toegang beperkt is.
|
|
Stromen en indeling |
Bepaal hoe het werk wordt gestructureerd en geordend voor de agent: wanneer deterministische stromen of onderwerpen moeten worden gebruikt, wanneer moet worden vertrouwd op indeling en wanneer menselijke betrokkenheid vereist is. Het doel is voorspelbaar gedrag, veilige automatisering en duidelijke escalatie.
Wanneer gebruikt u stromen of onderwerpen:- Gegevensverzameling in meerdere stappen
- Begeleide probleemoplossing of beslissingsbomen
- Compliance- of beleidsgestuurde processen
- Acties met grote impact of onomkeerbare acties
Onderwerpen zijn het belangrijkste mechanisme voor deterministische logica.
Definieer:- Wat de agent autonoom kan doen
- Wat menselijke goedkeuring, beoordeling of terzijdestelling vereist
- Wanneer de agent moet escaleren of uitstellen
- Hoe menselijke feedback terugvloeit naar verbetering
|
- Ask-Me-Anything-agent: Minimale deterministische stromen; berust vooral op indeling en generatief redeneren.
- Autonome agent: gebruikt stromen of onderwerpen om volgordebepaling, validaties en vangrails voor kritieke stappen af te dwingen.
- Goedkeuringsworkflows: De agent bereidt context en aanbevelingen voor; mensen keuren acties met een grote impact goed of negeren deze.
|
- Overstructurering van stromen, beperking van de flexibiliteit en het gevoel van stijfheid of broosheid van het middel.
- Het onderstructureren van stromen, het verminderen van de betrouwbaarheid en het onvoorspelbaar maken van de resultaten.
- Onderwerpen niet expliciet gebruiken voor deterministische logica, wat leidt tot ad-hoc of inconsistent gedrag.
- Vervaging van de verantwoordelijkheden tussen mens en agent, resulterend in onduidelijke escalatiepaden.
- Mensen overladen met goedkeuringen voor acties met een laag risico, waardoor knelpunten ontstaan en het gebruik van middelen wordt ontmoedigd.
- Agenten handelen zonder duidelijke grenzen voor niet handelen, vooral in extreme of risicovolle scenario's.
|
|
Instructies en gedrag |
Instructies definiëren het volgende:- De rol en verantwoordelijkheden van de agent
- Hoe het redeneert en reageert
- Wanneer en hoe het kennis, hulpmiddelen of andere middelen moet gebruiken
- De volgorde van acties die het moet volgen
- Toon, grenzen en veiligheidsregels
Duidelijke instructies verbinden kennis, hulpmiddelen en stromen tot een samenhangend, voorspelbaar systeem.
Meer informatie: Configureer hoogwaardige instructies voor generatieve indeling en Schrijf effectieve instructies voor declaratieve agenten. |
- Rol en reikwijdte: "U bent de IT Email Support Agent die verantwoordelijk is voor het lezen van inkomende mailboxberichten, het extraheren van ticketnummers en het antwoorden met gevalideerde informatie uit ServiceNow."
- Opeenvolgend gedrag: "Stap 1: Controleer de kennisbank op een bestaand beleid of een bekend probleem. Stap 2: Als de informatie niet wordt gevonden of onvolledig is, roep dan de ServiceNow-tool aan om de ticketdetails op te halen. Stap 3: Als er nog steeds noodzakelijke gegevens ontbreken, antwoord dan met een 'Ik weet het niet'-patroon en escaleer het probleem.
- Gebruiksregels voor de tool: "Valideer geëxtraheerde ID's altijd met een toolaanroep voordat u ze in antwoorden gebruikt."
- Foutafhandeling: "Ga niet raden als kennis ontbreekt of het aanroepen van een hulpprogramma mislukt. Reageer met een duidelijke beperking en vervolgstap.
|
- Instructies zijn te vaag. Bijvoorbeeld: "Help gebruikers met ondersteuningsproblemen" specificeert geen domein, grenzen of toegestane acties.
- Er is geen duidelijkheid over wanneer kennis, tools of andere agenten moeten worden gebruikt, wat leidt tot inconsistent of inefficiënt gedrag.
- De instructies definiëren de volgorde van acties niet, waardoor de agent kennis- en tooloutput op onvoorspelbare manieren combineert.
- Gebruiksregels voor tools zijn niet expliciet gedefinieerd, wat ertoe kan leiden dat tools onnodig of helemaal niet worden aangeroepen, of dat kennis- en tooloutput op onverwachte manieren worden gecombineerd.
- Tegenstrijdige instructies, zoals "stel altijd verduidelijkende vragen" en "reageer alleen met definitieve antwoorden".
- Geen expliciete richtlijnen voor wat "niet mag", zoals het wijzigen van gevoelige gegevens, het delen van interne identificatiegegevens of het geven van juridisch of HR-advies zonder geverifieerde bronnen.
|
|
Agentarchitectuur en -samenstelling |
Gebruik meerdere agenten wanneer:
- Domeinen groot of verschillend zijn
- Eigendom verschilt per team
- Toegang of machtigingen variëren
- Gespecialiseerde redenering vereist is
Delegatie verbetert de modulariteit duidelijkheid en onderhoudbaarheid op de lange termijn.
Meer informatie: Verken multi-agent indelingpatronen. |
- Een hoofdagent delegeert het opzoeken van tickets aan een IT-agent.
- Een kennisagent behandelt document-QA.
- Een routeringsagent bepaalt welke expertagent moet worden aangeroepen.
|
- Overdelegatie (te veel agenten) – bijvoorbeeld het creëren van een aparte agent voor elke kleine taak – kan leiden tot een onoverzichtelijke architectuur en maakt het moeilijk om de agenten te onderhouden, debuggen, beveiligen of updaten.
- Onderdelegatie (één gigantische agent) – bijvoorbeeld een enkele agent die HR-vragen moet beantwoorden, IT-tickets moet opzoeken, problemen moet oplossen en inkooporders en incidenten moet aanmaken – kan leiden tot een monolithische, kwetsbare agent die onmogelijk te onderhouden is.
- Ongedefinieerde delegatiegrenzen. Bijvoorbeeld, de hoofdagent weet niet wanneer hij moet overdragen, onderliggende agenten weten niet welke input ze moeten verwachten, of verantwoordelijkheden overlappen (twee agenten zoeken allebei IT-tickets op).
|
|
Governance en risicobeheer |
Definieer hoe de agent wordt beheerd, beveiligd en gemonitord om te zorgen voor duidelijkheid en onderhoudbaarheid op de lange termijn. Het gedraagt zich verantwoordelijk, veilig en voorspelbaar gedurende de gehele levenscyclus.
Deze definitie omvat toegangscontrole, actierechten, veiligheidsmechanismen, verantwoording en continu toezicht om zowel operationele als AI-gerelateerde risico's vanaf dag één te beheren.
Meer informatie: Vastleggen van governance-vereisten en Verantwoorde AI-principes toepassen. |
- Authenticatie- en toegangsmodel: De agent gebruikt identiteit op gebruikersniveau om alleen de gegevens op te halen die een gebruiker mag zien, terwijl identiteiten op systeemniveau beperkt zijn tot duidelijk gedefinieerde servicebewerkingen.
- Machtigingen en vangrails voor acties: de agent kan werknotities bijwerken of antwoorden opstellen, maar kan zonder goedkeuring geen onomkeerbare acties uitvoeren (zoals tickets sluiten of externe communicatie versturen).
- Veiligheids- en inhoudsbescherming: Gevoelige of gereguleerde informatie wordt gedetecteerd en geblokkeerd om te worden gedeeld of gebruikt met behulp van platformbeveiligingen (bijvoorbeeld gegevensverliespreventie of veiligheidsfilters).
- Logboekregistratie, controle en traceerbaarheid: alle acties van agenten, aanroepen van hulpprogramma's en escalaties worden geregistreerd en kunnen worden gecontroleerd voor naleving en beoordeling.
- Operationeel eigenaarschap: De agent heeft een gedefinieerde eigenaar, sponsor en operationele beheerder, waarbij machtigingen en gedrag regelmatig worden gecontroleerd.
|
- Het te laat ontwerpen van governance- en risicobeheersingsmaatregelen leidt tot geblokkeerde implementaties of productievertragingen.
- Het te veel machtigingen geven aan agenten "voor het gemak", waardoor het risico op datalekken of onbedoelde acties toeneemt.
- Het te weinig machtigingen geven aan agenten, wat leidt tot fouten tijdens de uitvoering wanneer vereiste systemen of gegevens ontoegankelijk zijn.
- Het niet integreren van verantwoordelijke AI-aspecten in kernbeslissingen op het gebied van governance.
- Zwakke operationele governance, zoals geen duidelijke eigenaar, geen monitoringplan of geen gedefinieerd proces voor incidentrespons.
- Het gedrag van agenten na implementatie niet controleren, ervan uitgaande dat vangrails alleen voldoende zijn.
|
|
Evaluatie en optimalisatie |
Definieer tests die realistische scenario's simuleren om de nauwkeurigheid, relevantie en kwaliteit van de antwoorden van uw agenten te meten. Geef een verwachte reactie en laat zien hoe de reactie van de agent overeenkomt met uw reactie of de meest standaardreactie.
Plan hoe de prestaties gemeten en verbeterd kunnen worden:
- Nauwkeurigheid en relevantie
- Tijdsbesparing of efficiëntie
- Adoptie en gebruik
- Signalen van tevredenheid en vertrouwen
- Kwaliteit van citaties
- Naleving van toestemmingsvereisten
- Detectie van onjuiste informatie
- Verhelderend vraaggedrag
Definieer welke telemetrie verzameld moet worden:
- Hulpmiddeloproepen
- Agentacties
- Fouten en herhaalpogingen
- Feedback van gebruikers
Beschouw evaluatie als onderdeel van het ontwerp, niet als een bijzaak. Meer informatie: Ontwerp en operationaliseer agentevaluatie. |
- Valideer dat het opzoeken van tickets de juiste status retourneert en geen verouderde status.
- Valideer dat citatielinks verwijzen naar actuele goedgekeurde content.
- Valideer dat de agent weigert details te verstrekken over het ticket van een andere persoon.
- Test of de agent een ticketnummer of KB-artikel verzint.
- Meet het aantal e-mails dat de autonome agent per dag verwerkt en het percentage gebruikers dat de agent verkiest boven handmatige kanalen.
|
- Evaluaties te laat uitvoeren (na de implementatie).
- Geen basislijn of benchmark.
- Evaluaties niet gekoppeld aan echte scenario's.
- Geen regressiedetectie.
- Geen evaluatie in meerdere stappen.
- Geen evaluator voor de kwaliteit van het toolgebruik.
- Alleen controleren op "happy paths".
- Telemetriehiaten.
|
