Agentforce-gids voor het waarborgen van betrouwbaar agentisch gedrag: een strategie met 6 niveaus van determinisme

Olfa Kharrat, Director of Product Management - Agentforce
Reinier van Leuken, Senior Director of Product Management - Agentforce

Vertrouwen is de toonaangevende waarde bij Salesforce. Dat is al zo sinds de oprichting in 1999, toen we met cloud computing en SaaS nieuwe technologische modellen introduceerden. Bedrijven vertrouwen erop dat Salesforce hun waardevolle bedrijfsdata veilig opslaat in de cloud. Ze weten immers dat deze data wordt beschermd door de juiste toegangscontroles. Dat is nog altijd van cruciaal belang, maar in het tijdperk van agentische AI is de definitie van vertrouwen nog breder. Nu bedrijven steeds meer vertrouwen op autonome agents om kritieke bedrijfsfuncties uit te voeren, moeten deze agents vertrouwde zakenpartners zijn die nauwkeurig, relevant en vooral betrouwbaar werk verrichten.

Maar hoe bouw je een betrouwbare agent? Betrouwbaarheid betekent meestal dat een bepaalde input steeds tot hetzelfde resultaat leidt. Alleen werken agents soms anders, omdat ze worden aangestuurd door grote taalmodellen (LLM's) die van nature niet-deterministisch zijn. Dit geeft agents de flexibiliteit om creatieve oplossingen te ontwikkelen die zijn afgestemd op specifieke omstandigheden, zonder dat je elke omstandigheid of situatie expliciet hoeft te programmeren. Agents moeten echter worden beheerd om te voldoen aan zakelijke vereisten en operationele richtlijnen. Bij het uitvoeren van bedrijfsprocessen moeten ze aantoonbaar betrouwbaar zijn en bedrijfsresultaten produceren die voldoen aan deterministische beperkingen. Determinisme legt een rigiditeit en discipline op die botst met de autonomie en flexibiliteit die agents kunnen bieden. Om succesvolle agents te kunnen creëren, moet je dan ook de juiste balans vinden tussen creatieve flexibiliteit en zakelijke controle.

Dit document gaat in op de belangrijkste overwegingen voor het ontwikkelen van betrouwbare agents. Het definieert zes niveaus van agentische controle en biedt best practices voor het beheer van agentisch gedrag voor elk van deze niveaus. Deze richtlijnen gaan in op de manieren waarop de redeneringsengine van Agentforce werkt. Naarmate Agentforce groeit, zal dit document worden bijgewerkt met de nieuwste best practices.

Dit document gaat uit van een basiskennis van het ontwerpen en bouwen van Agentforce-agents. Voor een introductie tot Agentforce raden we het volgende aan:

• Bekijk de informatie op agentforce.com.
• Volg de trail Become an Agentblazer Champion . Deze trail introduceert de belangrijkste AI-concepten en helpt je bij het bouwen van een basisagent voor essentiële taken.
• Lees meer over Agentforce op help.salesforce.com , met name Design and Implement Agents . Deze leskaart begeleidt je bij alle belangrijke levenscyclusstappen, van het bedenken van je oplossing en het instellen en configureren van je agent, tot het testen, implementeren en monitoren.

Om agentisch gedrag beter te begrijpen, vergelijken we agents eerst met hun rigide tegenhangers: chatbots.

Chatbots: rigide regelvolgers

Chatbots volgen vooraf bepaalde beslisbomen die structureren aan welke dialogen ze kunnen deelnemen. Het doorlopen van deze beslisbomen is afhankelijk van de antwoorden die de gebruiker geeft. Dit antwoord kan een selectie zijn uit een vooraf bepaalde reeks opties of een vrij tekstantwoord. Bij een vrij tekstantwoord wordt een voorspellend model gebruikt om de intentie te classificeren. Deze bomen omvatten alle mogelijke gesprekstrajecten en dicteren de antwoorden van de chatbot bij elke stap. Het gedrag van de chatbot wordt volledig bepaald door vooraf ingestelde regels. Als de input van een gebruiker niet overeenkomt met een herkend pad of als het voorspellende model niet is getraind om een bepaalde intentie te herkennen, kan de chatbot niet correct reageren.

Agents: flexibel en intuïtief

Agents daarentegen maken gebruik van de kracht van LLM's en hun geavanceerde mogelijkheden op het gebied van natuurlijke-taalverwerking (NLP). LLM's stellen agents in staat om de intentie achter de input van een gebruiker te begrijpen, zelfs als deze op een onverwachte manier wordt geformuleerd. Op basis van zijn begrip van de intentie kan de agent de meest geschikte actie uit een reeks mogelijkheden selecteren. Een agent kan zelfs geheel nieuwe antwoorden formuleren. Deze flexibiliteit en dit aanpassingsvermogen onderscheiden agents van chatbots.

Een culinaire analogie

Je kunt het onderscheid tussen chatbots en agents vergelijken met het verschil tussen een beginnende kok en een doorgewinterde chef-kok.

• De beginnende kok (chatbot) vertrouwt volledig op een gedetailleerd recept met exacte hoeveelheden, stapsgewijze instructies en specifieke kooktijden. Elke afwijking van het recept leidt tot een rampzalig gerecht. Op dezelfde manier moet een chatbot functioneren binnen de grenzen van zijn voorgeprogrammeerde beslisboom.
• Doorgewinterde chef-koks (agents) profiteren van een jarenlange ervaring en hun intuïtie. Omdat ze in grote lijnen weten wat je voorkeuren zijn, kunnen ze aan de hand van een korte beschrijving van de ingrediënten een heerlijke maaltijd bereiden die voldoet aan je behoeften. De exacte stappen kunnen elke keer variëren en het gerecht kan verschillende varianten hebben, maar het resultaat is altijd bevredigend. Ook kan een agent zijn aanpak aanpassen op basis van de context en intentie van de input van de gebruiker, wat resulteert in een succesvolle interactie.

Kortom: het fundamentele verschil met chatbots is dat agents zich kunnen aanpassen en om kunnen gaan met onverwachte input.

Een onderscheidend kenmerk van de intelligentie van een agent is het vermogen om de meest geschikte acties op het juiste moment te vinden en te activeren. Door deze flexibiliteit is het niet nodig om elke mogelijke gebruikersinteractie tot in detail te programmeren.

Het bouwen van een agent in Agentforce bestaat uit onderwerpen, acties, en instructies en beschrijvingen in natuurlijke taal.

Onderwerpen

Onderwerpen zijn de taken die moeten worden uitgevoerd door de agent. Onderwerpen hebben kenmerken zoals een classificatiebeschrijving, bereik en instructies die elke taak en het uitvoeren ervan definiëren. Onderwerpen bevatten acties die de agent kan uitvoeren, samen met instructies die bepalen op welke manier deze acties worden uitgevoerd.

Acties

Acties zijn de vooraf gedefinieerde taken die de agent kan uitvoeren om zijn taak te voltooien. Er zijn vijf verschillende soorten acties:

• voer Apex-code uit
• roep een API aan
• voer een stroom uit
• krijg een LLM-antwoord op een taakaanwijzingssjabloon
• roep een voorspellend model aan

Instructies en beschrijvingen in natuurlijke taal

De definitie van een agent bevat instructies in natuurlijke taal die de activa van de agent beschrijven en de richtlijnen definiëren waarbinnen de agent moet werken. Er worden instructies geschreven voor acties en onderwerpen.

• Acties. Een actie bevat:
  • instructies die beschrijven wat de actie doet, zodat de redeneringsengine weet wanneer deze actie moet worden uitgevoerd.
  • inputs met een beschrijving in natuurlijke taal, zodat de agent ze kan voorbereiden.
  • outputs met een beschrijving in natuurlijke taal van format en gebruik.
• Onderwerp. Een onderwerp bevat instructies die bepalen hoe acties op een hoger niveau moeten worden uitgevoerd. Instructies kunnen bijvoorbeeld kaders specificeren voor de tone of voice, de gewenste volgorde van acties, mogelijke voorwaarden of wanneer gesprekken naar mensen moeten worden doorgezet. Het onderwerp bevat ook een classificatiebeschrijving en een afbakening van het bereik. Al deze onderdelen zorgen ervoor dat de agent binnen het bereik van de gedefinieerde rol blijft en de taak uitvoert.
• Data. Agents hebben data nodig om hun taken te kunnen uitvoeren. Data kan gestructureerd (zoals CRM-data) of ongestructureerd (zoals knowledge-base-artikelen van het bedrijf) zijn. Agents hebben toegang tot data via actie-inputs. Een actie kan bijvoorbeeld een taakaanwijzingssjabloon aanroepen dat is gebaseerd op CRM-data of is verrijkt met stukjes ongestructureerde data met behulp van RAG-technieken.

Als agents bestaan uit de correcte bouwstenen, kunnen ze het beoogde doel bereiken en binnen de juiste grenzen werken.

De redeneringsengine van Agentforce beheert deze bouwstenen en zorgt zo voor het juiste agentische gedrag. Hij maakt gebruik van de instructies en beschrijvingen in natuurlijke taal die zijn gedefinieerd in de onderwerpen en de acties. De engine is gebouwd op ReAct, een nieuw redeneringsparadigma voor LLM's dat in 2022 werd geïntroduceerd door Yao et al. Dit paradigma bootst het taakbeheer door mensen na door te redeneren over een probleem, actie te ondernemen, de resultaten van de actie te observeren en de cyclus te herhalen totdat de taak is voltooid.

Salesforce-agents houden zich aan dit paradigma:

1. Redeneren: Begrijp de intentie van de gebruiker en stem deze af op het juiste onderwerp en de juiste actie(s).
2. Actie uitvoeren: Start de juiste actiereeks.
3. Observeren: Beoordeel de resultaten van de acties op basis van de intentie van de gebruiker. Als de intentie niet wordt vervuld, redeneer dan verder op basis van het tot nu toe verkregen resultaat en van de instructies en beschrijvingen van onderwerp/actie. Als aan de intentie is voldaan, geef dan het definitieve antwoord en houd je aan eventuele opmaakinstructies.
4. Herhalen: Herhaal deze stappen totdat de laatste stap in de instructies is bereikt.

De redeneringsengine gebruikt LLM's voor elke redenerings- en observatiestap. Afhankelijk van het actietype kan het ook LLM's gebruiken in de stap 'Actie uitvoeren'.

Dit gedeelte beschrijft een gelaagde aanpak om het determinisme van agents te verbeteren. Elk niveau bouwt voort op het vorige, met toenemende complexiteit en mogelijkheden die je meer controle over het gedrag van de agent geven.

Het eerste niveau richt zich op het zelfstandig identificeren van relevante onderwerpen, waarna de juiste acties worden geselecteerd op basis van doelen in plaats van expliciete instructies. Het kernmechanisme omvat het gebruik van een contextueel begrip om te reageren op input van gebruikers. Hoewel technisch gezien elk type actie kan worden toegevoegd, gaan we er op dit niveau vanuit dat de acties taakaanwijzingsacties zijn. Instructievrije onderwerpen met taakaanwijzingsacties zorgen voor een snelle en efficiënte afhandeling van veelvoorkomende vragen.

Op dit niveau ligt de nadruk op het vaststellen van een basisniveau van responsiviteit en autonomie van agents door middel van een dynamisch begrip.

Dit niveau bouwt voort op de basis van de instructievrije actieselectie en voegt expliciete instructies toe om het gedrag van agents te bepalen. Het toevoegen van nauwkeurige instructies geeft je meer controle over de manier waarop agents reageren op verschillende situaties. Instructies voor agents kunnen worden uitgedrukt als regels, richtlijnen, vangrails en voorbeelden. Deze geven de agent specifieke instructies voor het omgaan met verschillende onderwerpen, het uitvoeren van acties en het verwerken van hun output. Op dit niveau krijgt de agent een duidelijke sturing om de consistentie te vergroten en de naleving van bedrijfsrichtlijnen en -processen te verbeteren.

Grounding betekent dat het begrip en de antwoorden van de agent worden gebaseerd op externe kennisbronnen. Dankzij grounding is de informatie die door de agent wordt verstrekt nauwkeuriger, actueler en relevanter. Dit niveau integreert de toegang tot databases, knowledge bases en andere informatiebronnen. Omdat de antwoorden van de agent zijn gebaseerd op geverifieerde data, zijn ze betrouwbaarder.

Op dit niveau kunnen agents met variabelen werken. Met variabelen kunnen agents interacties personaliseren, context onthouden tijdens verschillende interacties en hun gedrag dynamisch aanpassen op basis van specifieke datapunten tijdens de agentsessie. Een agent kan bijvoorbeeld gebruikersvoorkeuren, orderdata en andere relevante informatie vastleggen en die data vervolgens gebruiken voor een interactie op maat. Met variabelen zijn agents beter in staat om complexere, meer voorgeschreven en meer gepersonaliseerde interacties te verzorgen.

Deze stap integreert de agent met de kernfunctionaliteiten van Salesforce: Apex, API's en stromen. Integratie stelt de agent in staat om complexe acties uit te voeren binnen het Salesforce-ecosysteem, zoals het openen en bewerken van data, het activeren van workflows en interactie met andere systemen.

• Apex levert programmatische controle.
• API's zorgen voor naadloze integratie met andere applicaties.
• Stromen maken de automatisering van complexe bedrijfsprocessen mogelijk.

Dit niveau maakt van de agent een krachtige tool die geavanceerde taken kan uitvoeren en direct kan bijdragen aan de bedrijfsresultaten.

Dit laatste niveau bouwt voort op de technische integraties van niveau 5 en introduceert de deterministische redenering om de kloof tussen probabilistische AI en rigide bedrijfslogica te overbruggen. Waar eerdere niveaus door een LLM laten bepalen welke tool je moet gebruiken, stelt Agent Script je in staat om het redeneringsproces zelf te programmeren. Met behulp van een documentachtig canvas of directe code kun je onveranderlijke paden definiëren. Denk daarbij aan verplichte verificatiepoorten, voorwaardelijke 'if/else'-vertakking en onderwerpovergangen die de agent verplicht moet volgen, ongeacht de gebruikersinvoer. Met deze hybride redenering kun je de gespreksflexibiliteit van een LLM combineren met gegarandeerde-uitvoeringslagen. Niveau 6 verandert de agent in een zero-trust partner op bedrijfsniveau die uiterst nauwkeurig kan omgaan met essentiële naleving, kennisgevingen van regelgeving en complexe afhankelijkheden met meerdere stappen.

Deze agent bestaat uitsluitend uit onderwerpen en acties met de bijbehorende beschrijvingen. Dit is de ondergrens van reactievermogen en autonomie. Aan de hand van deze voorbeeldagent kunnen we de verschillende stappen van de redeneringsengine introduceren en laten zien hoe hij deze beschrijvingen gebruikt om de juiste onderwerpen te selecteren en vervolgens acties uit te voeren. Door de onderwerpinstructies uit dit voorbeeld weg te laten, zien we dat agents op dit eerste niveau de grootste mate van vrijheid hebben in vergelijking met agents op hogere niveaus. Op niveau 1 kan de agent in volledige vrijheid de actie selecteren die hij geschikt acht, uitsluitend op basis van het lopende gesprek.

Belangrijke overwegingen met betrekking tot de redeneringsengine:

• De configuratie-instellingen liggen vast voor de LLM van de redeneringsengine. Agentbouwers kunnen ze niet veranderen. Momenteel kan de agentbouwer voor de redenering kiezen tussen een LLM van OpenAI of een LLM van Anthropic die wordt gehost op de Salesforce-infrastructuur. Dit kan veranderen naarmate er meer modellen worden toegevoegd.
• Standaardgeschiedenis van de redeneringsengine: Wanneer een verzoek wordt gedaan aan de redeneringsengine (stap 2-5), haalt deze automatisch de geschiedenis van de meest recente verzoeken en antwoorden op. Dit zorgt ervoor dat de gesprekscontext behouden blijft voor de redeneringsengine. Naast klantinteracties omvatten deze aanroepen naar het LLM van de planner ook aanroepen naar het LLM van de redeneringsengine voor andere aanvragen, zoals onderwerpselectie.

Het redeneringsproces omvat vier stappen:

1. Onderwerpselectie
2. Actieselectie
3. Agentische lus
4. Groundingcontrole

Onderwerpen zijn ontworpen om de nauwkeurigheid te verbeteren waarmee agents de juiste actie of volgorde van acties classificeren. Elk onderwerp moet bestaan uit semantisch afzonderlijke acties die allemaal tot een beknopte onderwerpbeschrijving en dus tot een vergelijkbare agentfunctie kunnen behoren.

Het juiste onderwerp wordt geselecteerd door het redeneringsengine-LLM (stap 2-3 van het diagram). Dit selecteert het onderwerp waarvan de classificatiebeschrijving het meest overeenkomt met de laatste uiting, met behulp van een onderwerptaakaanwijzing. Deze taakaanwijzing bevat de classificatiebeschrijvingen van alle onderwerpen en de gespreksgeschiedenis. Naast uitingen en antwoorden van agents omvat de gespreksgeschiedenis ook de uitgevoerde acties en hun resultaten. Bovendien bevat de taakaanwijzing cruciale instructies die analyse binnen de context van de gespreksgeschiedenis mogelijk maken en vereisen dat het LLM zijn denkproces deelt.

Aanvullende overwegingen:

• Naast de zichtbare onderwerpen wordt er automatisch een extra verborgen onderwerp toegevoegd voor 'off topic'-uitingen. Dit onderwerp wordt geselecteerd als er geen ander bestaand onderwerp overeenkomt met de uiting. Hiermee kunnen agents onjuiste classificatie voorkomen. Dit onderwerp heeft geen acties. Het bestaat alleen om de redeneringsengine te helpen later een passend antwoord te formuleren.
• Alleen de naam en de classificatiebeschrijving van het onderwerp worden gebruikt in de onderwerptaakaanwijzing.
• Het redeneringsengine-LLM kan slechts één onderwerp tegelijk kiezen.
• Gesprekken kunnen onverwacht een andere wending nemen. Wanneer een uiting wordt ontvangen, gaat de redeneringsengine verder naar de selectie van het onderwerp, wat betekent dat bij elke nieuwe uiting een nieuw onderwerp kan worden gekozen.

Het doel van onderwerpen is tweeledig:

1. Verminderen van het risico dat de redeneringsengine verward raakt door acties te groeperen. Dit voorkomt dat de engine de verkeerde acties selecteert.
2. De selectie en het uitvoeren van acties sturen met instructies (meer hierover bij niveau 2: Agentische controle: instructies toevoegen).

Door de capaciteiten van agents zorgvuldig te organiseren in duidelijk gedefinieerde onderwerpen die bestaan uit gerelateerde acties, worden ze effectiever en voorspelbaarder en is het gemakkelijker om ze te updaten en uit te breiden. Er zijn twee benaderingen voor het ontwerpen van onderwerpen: top-down en bottom-up.

• In de top-down benadering worden onderwerpen eerst ontworpen als taken op hoog niveau die door de agent moeten worden uitgevoerd. De individuele acties worden vervolgens voor die onderwerpen gedefinieerd.
• In de bottom-up-benadering worden eerst alle individuele acties gedefinieerd, om ze vervolgens te groeperen op onderwerp.

Beide benaderingen leiden tot goede resultaten als ze goed worden uitgevoerd.

Bottom-up-benadering

In dit gedeelte wordt de bottom-up-benadering behandeld, omdat deze nauw aansluit bij de redenen waarom de redeneringsengine onderwerpen nodig heeft.

Stap 1: maak een lijst van alle agentische acties

Maak eerst een lijst van alle specifieke acties die de agent moet kunnen uitvoeren. In dit stadium moet je het niet te algemeen houden en kun je beter heel specifiek zijn. Probeer acties niet te snel te groeperen of te vereenvoudigen. Het doel is om een uitgebreid en gedetailleerd beeld te creëren van waar de agent toe in staat is.

Voor een klantenservicemedewerker kan de eerste lijst bijvoorbeeld het volgende bevatten:

• Een bestelling retourneren: wordt gebruikt om het retourproces voor een bestelling te starten.
• Beschikbaarheid uit voorraad controleren: wordt gebruikt om te controleren of een product op voorraad is.
• Beleid voor productomruiling controleren: wordt gebruikt om informatie over omruilbeleid op te halen.
• Vragen beantwoorden op basis van kennis: wordt gebruikt om algemene of FAQ-achtige vragen te beantwoorden.
• Controleren op promoties: wordt gebruikt om te controleren op beschikbare promoties of kortingen.
• Leverdatum voorspellen: wordt gebruikt om de verwachte leverdatum/-tijd te schatten.
• Orderstatus controleren: wordt gebruikt om de huidige status van de bestelling van een klant te achterhalen.
• Klantorders zoeken: wordt gebruikt om alle eerdere of actieve bestellingen van een specifieke klant op te halen.
• Technische problemen oplossen: wordt gebruikt om technische problemen met een product of service op te lossen.
• Voorwaarden zoeken voor klantorders: wordt gebruikt om alle voorwaarden op te halen met betrekking tot een bestelling.
• Klantactiva vinden: wordt gebruikt om activa te identificeren of op te halen met betrekking tot een klant.
• Het bezorgadres wijzigen.

Denk eraan dat een actie als 'klachten van klanten oplossen' in dit stadium te breed is. Acties moeten volgen uit een zo gedetailleerd mogelijk omschreven gedrag van agents. Er kunnen veel verschillende soorten klachten zijn en verschillende acties voorzien hier al in:

• Problemen na bezorging - zoals het oplossen van problemen met beschadigde of slecht werkende producten - worden al behandeld door 'Technische problemen oplossen'.
• Problemen voorafgaand aan de bezorging - zoals niet-plaatsgevonden bezorgingen, het wijzigen van leverdata of het aanpassen van bestellingen - worden al behandeld door acties zoals 'Orderstatus controleren', 'Leverdatum voorspellen' of 'Een bestelling retourneren'.
• Algemene vragen van klanten - zoals vragen over het beleid - worden al behandeld in 'Vragen beantwoorden op basis van kennis' of 'Beleid voor productomruiling controleren'.

Stap 2: markeer actieparen (of veelvouden) die mogelijk verwarring bij de redenering veroorzaken

Markeer acties die van zichzelf vergelijkbaar zijn, omdat deze voor verwarring kunnen zorgen bij de redeneringsengine. De semantische verschillen in hun beschrijvingen zijn niet duidelijk genoeg. Daardoor weet de redeneringsengine niet welke actie moet worden geselecteerd in stap 5.

'Technische problemen oplossen' en 'Vragen beantwoorden op basis van kennis' hebben bijvoorbeeld vergelijkbare beschrijvingen, maar hun functionaliteit kan aanzienlijk verschillen. Het markeren van dergelijke semantische overlappingen helpt bij het identificeren van acties voor verschillende onderwerpen.

Stap 3: groepeer acties in voorlopige onderwerpen

Zodra acties duidelijk zijn gedefinieerd en hun semantische overlappingen zijn geïdentificeerd, kunnen acties worden gegroepeerd in voorlopige onderwerpen. Een onderwerp is een logische functiecategorie, een groepering van acties die samen een samenhangende capaciteit of vaardigheid van de agent vertegenwoordigen.

Let op het volgende bij het maken van deze groepen:

• Vermijd semantische overlapping door het minimale aantal benodigde onderwerpen te gebruiken.
• Zorg ervoor dat elk onderwerp daadwerkelijk gerelateerde acties bevat.
• Zorg ervoor dat ondersteunende acties die in een reeks moeten worden uitgevoerd in hetzelfde onderwerp voorkomen.

Hier is een voorbeeld van een voorlopige groepering voor een klantenservicemedewerker:

Onderwerp 1:

• Retourneer een bestelling
• Controleer de voorraad
• Controleer het beleid voor productomruiling
• Bekijk promoties
• Voorspel de leverdatum
• Zoek voorwaarden voor klantorders
• Controleer de orderstatus
• Vind bestellingen van klanten
• Vind activa van klanten
• Beantwoord vragen op basis van kennis
• Wijzig het bezorgadres

Onderwerp 2:

• Los technische problemen op
• Vind activa van klanten

Stap 4: schrijf classificatiebeschrijvingen voor onderwerpen en deel onderwerpen zo nodig op

Zodra je de voorlopige groepering hebt gemaakt, schrijf je classificatiebeschrijvingen voor elk onderwerp.

• Onderwerp 2 in ons voorbeeld gaat duidelijk over technische problemen met producten.
• Onderwerp 1 heeft echter een breder spectrum. Het gaat voornamelijk over orderbeheer, maar bevat ook enkele acties die hier geen verband mee houden, zoals het controleren op promoties en het beantwoorden van vragen op basis van kennis. Onderwerp 1 kan niet duidelijk en beknopt in één zin worden beschreven. Daarom moet het worden opgesplitst in verschillende onderwerpen.

Na deze verfijning is dit het resultaat:

• Onderwerp 1: orderbeheer: Beschrijft acties met betrekking tot het beheren en wijzigen van klantorders en gerelateerde logistiek, behalve alles wat verband houdt met omruiling en retourzending.
  • Controleer de voorraad: bepaal of een product op voorraad is.
  • Voorspel de leverdatum: schat wanneer een bestelling aankomt.
  • Controleer de orderstatus: vind de status van de bestelling van een klant.
  • Vind bestellingen van klanten: haal alle bestellingen op die door een klant zijn geplaatst.
  • Het bezorgadres wijzigen.
• Onderwerp 2: problemen oplossen
  • Vind activa van klanten: haal de geregistreerde apparaten of producten van de klant op.
  • Los technische problemen op: bied technische ondersteuning of diagnostiek.
• Onderwerp 3: omruiling: Beschrijft acties met betrekking tot het omruilen en retourneren van bestellingen.
  • Retourneer een bestelling: start het retourproces voor bestellingen.
  • Controleer het beleid voor productomruiling: geef de omruilingsregels voor producten.
  • Vind bestellingen van klanten: haal alle bestellingen op die door een klant zijn geplaatst.
  • Voorwaarden zoeken voor klantorders: haal alle voorwaarden op met betrekking tot een bestelling.
• Onderwerp 4: productondersteuning: Beschrijft transversale acties die worden gebruikt voor het ophalen en doorsturen van informatie.
  • Beantwoord vragen op basis van kennis: reageer op algemene vragen van klanten met behulp van informatie uit de knowledge base.
  • Bekijk promoties: bekijk huidige promoties of kortingen.

Dus samengevat: maak eerst een uitgebreide lijst van alle mogelijke acties en markeer vervolgens semantische overlapping tussen deze acties. Maak vervolgens een set onderwerpen die minimaal alle semantische overlappingen oplost (zodat de redeneringsengine niet in de war raakt bij de afhandeling van één onderwerp). Schrijf vervolgens de classificatiebeschrijving van elk onderwerp. Als de onderwerpen te breed zijn geformuleerd, verdeel ze dan in meer gedetailleerde onderwerpen. Door deze richtlijnen te implementeren, bouw je een agent die niet alleen goed presteert, maar ook gemakkelijk te onderhouden en uit te breiden is.

Deze structuur zorgt voor een betere redenering, een nauwkeurigere uitvoering en duidelijkere beslissingsgrenzen binnen het gedrag van de agent. Ook de samenwerking tussen ontwerpers, engineers en experts op het gebied van de betreffende onderwerpen is belangrijk. Zo maak je de agent transparanter en modulair.

Verdere overwegingen voor het effectief creëren van onderwerpen

• Optimaal aantal onderwerpen: Om ervoor te zorgen dat LLM's het juiste onderwerp beter classificeren, is het over het algemeen raadzaam om niet meer dan tien onderwerpen te hebben. Dit is echter maar een vuistregel. Bovendien moet elk onderwerp een duidelijke en onderscheidende beschrijving hebben. Uiteindelijk hangt het optimale aantal onderwerpen af van het semantische verschil tussen de classificatiebeschrijvingen van de onderwerpen. Als de onderwerpen erg verschillende classificatiebeschrijvingen hebben, is het risico op overlappingen van onderwerpen veel minder groot. Hier vind je meer best practices om overlapping tussen onderwerpen te voorkomen.
• Balans tussen omvang en duidelijkheid van onderwerpen: Over het algemeen is het beter om acties en instructies onder te verdelen in kleinere onderwerpen, omdat dit de classificatie eenvoudiger maakt. Toch kan het creëren van te veel onderwerpen met zeer vergelijkbare beschrijvingen tot verwarring leiden, net zoals semantische overlapping tussen acties leidt tot een onjuiste classificatie. Daarom zijn duidelijke, semantisch gedifferentieerde onderwerpbeschrijvingen van groot belang. Je kunt LLM's gebruiken om je te helpen bij het maken van deze goed gedifferentieerde classificaties.
• Standaardtaal en contextuele duidelijkheid: LLM's herkennen mogelijk geen specifieke zakelijke definities en afkortingen. Gebruik dus standaardtaal of wees zeer expliciet bij het uitleggen van de betekenissen van woorden binnen je specifieke context.
• Alleen de onderwerptitel en -beschrijving worden in de onderwerptaakaanwijzing verzonden. Daarom heeft het wijzigen van het bereik of de instructies van het onderwerp geen invloed op de selectie van het onderwerp.

Praktijkvoorbeeld

Stel je voor dat een klantenservicemedewerker een vraag krijgt over de garantiebepalingen van een horloge. De garantiekwestie lijkt geen verband te houden met het omruilen of de support van het product. Orderbeheer lijkt het meest geschikte onderwerp om aan dit verzoek te voldoen. Daarom wordt dit onderwerp door de redeneringsengine gekozen als het meest waarschijnlijke dat aan het verzoek kan voldoen.

Na de onderwerpselectie selecteert de redeneringsengine de juiste acties voor het gekozen onderwerp. Nogmaals: het redeneringsengine-LLM is hiervoor verantwoordelijk, waarbij deze gebruikmaakt van de observatietaakaanwijzing. Het doel van de observatietaakaanwijzing is om de volgende stap in het redeneringsproces te verkrijgen. Deze stap kan een van de volgende zijn:

• Een actie starten
• Vragen om actie-inputs aan van de gebruiker
• Vragen om een toelichting op het verzoek van de gebruiker
• Verzenden van het definitieve antwoord naar de gebruiker (waarbij aan het verzoek van de gebruiker wordt voldaan) zodra de actielus is voltooid (zie voor meer informatie redeneringsstap 3)

De input voor de observatietaakaanwijzing wordt gevormd door alle beschrijvingen van alle acties voor het onderwerp, evenals de gespreksgeschiedenis.

Best practices voor het ontwerpen van acties

Acties zijn de vooraf gedefinieerde taken die de agent kan uitvoeren om aan een verzoek te voldoen. Acties zijn de meest verfijnde definities van werk. Er zijn vijf verschillende soorten agent-acties: (1) Apex-code uitvoeren, (2) een API aanroepen, (3) een stroom uitvoeren, (4) een LLM-antwoord krijgen op een taakaanwijzingssjabloon en (5) een voorspellend model aanroepen. De meeste van deze acties kunnen deterministisch zijn. Een uitzondering is het krijgen van een antwoord op een taakaanwijzingssjabloon (op voorwaarde dat het externe systeem, de stroom- of de Apex-actie geen probabilistische elementen bevat, zoals het aanroepen van taakaanwijzingen). We behandelen deze kwesties in het gedeelte over het vijfde niveau van agentische controle.

1. Agentisch gedrag in taakaanwijzingsacties beheren: Er zijn twee manieren om controle uit te oefenen over het agentisch gedrag in taakaanwijzingsacties: (1) voeg meer instructies toe aan het taakaanwijzingssjabloon via engineering van taakaanwijzingen en (2) configureer de hyperparameters van het LLM dat de taakaanwijzingsreactie genereert, met name de temperatuur (zie documentatie ). Het verlagen van de temperatuur vermindert de variabiliteit in de gegenereerde antwoorden, wat de herhaalbaarheid en betrouwbaarheid van de agent verhoogt.
2. Optimaal aantal acties binnen één onderwerp: Net als bij het maximum aantal onderwerpen mag het aantal acties binnen een onderwerp in principe niet groter zijn dan tien. Maar nogmaals, dit is slechts een vuistregel. Het wordt voornamelijk bepaald door het semantische verschil tussen de acties. Wanneer acties duidelijk te onderscheiden zijn door hun beschrijving, kan dit aantal groter zijn. Er is echter geen numerieke meting voor semantische verschillen. Dit is aan de interpretatie van de Agentbuilder. Hoe groter het verschil in betekenis tussen de actiebeschrijvingen, hoe groter het semantische verschil. Overlapping moet hier te allen tijde worden vermeden.
3. Actiebeschrijvingen: In tegenstelling tot wat de naam suggereert, is de 'actie-instructie' eigenlijk een instructie die het redeneringsengine-LLM gebruikt om de juiste actie voor het onderwerp te selecteren. Merk op dat het gebruik van semantisch verschillende actiebeschrijvingen de kwaliteit van hun classificaties aanzienlijk kan verbeteren. Bekijk deze beschrijvingen zorgvuldig en vergelijk vooral alle actiebeschrijvingen die bij één onderwerp horen.

Praktijkvoorbeeld

Laten we verdergaan met het eerder genoemde voorbeeld, waarin een klantenservicemedewerker een vraag krijgt over de garantiebepalingen van een horloge. Na het selecteren van het onderwerp Orderbeheer wordt de meest waarschijnlijke actie gekozen. Omdat dit over orderbeheer gaat, is de eerste logische stap het opzoeken van de bestelling (waar moet je anders garantiebepalingen voor ophalen?) door de actie 'zoeken naar bestellingen' te starten.

Een uiting van een gebruiker kan de uitvoering van meerdere acties activeren voordat een antwoord naar de gebruiker wordt gestuurd. Dit komt door de agentische lus, die de meest geschikte vervolgactie blijft selecteren en uitvoeren tot er aan een van de volgende voorwaarden is voldaan:

• Het redeneringsengine-LLM bepaalt dat het verzoek is afgehandeld. In dit geval concludeert het dat aan het verzoek van de gebruiker is voldaan. Een deel van deze controle betreft een groundingcontrole, waarbij wordt geverifieerd dat het antwoord is gebaseerd op de actie-outputs. Het redeneringsengine-LLM mag zelf geen informatie bedenken voor het antwoord, omdat dit kan leiden tot hallucinaties of anderszins onjuiste antwoorden.
• Er zijn geen geschikte acties meer gevonden.
• Het maximaal toegestane aantal LLM-aanroepen voor de huidige stap is bereikt. Dit aantal wordt bepaald door de redeneringsengine zelf.

Acties zijn niet onderhevig aan een specifieke time-out. Zo wordt onderbreking voorkomen wanneer de uitvoeringsduur van acties variëren op basis van hun complexiteit. Sommige acties zijn nu eenmaal complexer om uit te voeren dan andere.

Praktijkvoorbeeld

Na het starten van het opzoeken van een bestelling beoordeelt de redeneringsengine het tot nu toe gegenereerde antwoord. Vervolgens besluit deze dat hij meer werk moet doen voordat een antwoord naar de gebruiker kan worden gestuurd. Nu de bestelling aanwezig is in de gespreksgeschiedenis, gaat de engine de garantiebepalingen opzoeken.

Daarbij realiseert de agent zich echter dat de klant twee horloges heeft gekocht, zoals blijkt uit het resultaat van de actie 'zoeken naar bestellingen'. Daarom besluit de redeneringsengine in de agentische lus om de klant te vragen voor welk horloge hij de garantiebepalingen nodig heeft.

Vermijd te gedetailleerde beschrijvingen

Vermijd te gedetailleerde beschrijvingen van de manieren waarop agents gesprekken met gebruikers moeten voeren. Te gedetailleerde beschrijvingen tasten het vermogen van een agent aan om een relatie op te bouwen, unieke gebruikersbehoeften te begrijpen en in realtime effectief te reageren op dynamische omstandigheden. Bovendien kunnen lange instructies de agent trager laten reageren en de redeneringsengine in verwarring brengen. Het forceren van determinisme via instructies heeft niet de voorkeur.

Wat je niet moet doen

Het is bijvoorbeeld niet nodig om een agent te vertellen dat deze niet naar concurrenten moet verwijzen bij antwoorden voor de klantenservice. Dit kan leiden tot ongewenst gedrag, omdat de agent dan ook kan weigeren vragen te beantwoorden over integratie met een aanbieder die ook een concurrent is. In plaats daarvan kan de instructie zoiets zijn als "houd bij het bespreken van concurrenten het belang van het bedrijf in gedachten". Dit voorkomt beperkende, voorwaardelijke instructies zoals "vermeld alleen concurrent xyz in het geval van…" en maakt in plaats daarvan gebruik van de redeneringsmogelijkheden van het LLM. Dit voorbeeld laat zien hoe instructies kunnen worden gegeven op een hoger, meer abstract niveau. Dit is vergelijkbaar met de manier waarop nieuwe menselijke klantenservicemedewerkers worden getraind.

Laten we eens kijken naar meer voorbeelden van wat je niet moet doen. Dit zijn enkele slechte instructies aan een serviceagent die kandidaatprofielen verwerkt op een wervingswebsite. Deze instructies proberen te anticiperen op elke mogelijke uiting van de klant en moeten daarom worden vermeden:

Instructie 1: De agent ontvangt de volgende uiting: "Kan ik een foto toevoegen aan mijn profiel?". Vraag de klant dan direct: "Wat is je profieltype?"

Instructie 2: Als de klant aangeeft een premiumprofiel te hebben, antwoord dan "Ik zal je contractgegevens controleren", zoek dan naar contractgegevens en controleer of is overeengekomen dat de klant de profielfoto kan aanpassen.

Als is overeengekomen dat de kandidaat dit mag doen, antwoord dan: "Ja, dat is mogelijk, ik zal het voor je aanpassen. Kun je me je nieuwe foto geven?" Zodra de foto is ontvangen, pas je het profiel van de kandidaat aan. Als het contract niet voorziet in het aanpassen van de profielfoto, zeg je: "Sorry, dit is niet mogelijk. Ik breng je in contact met een menselijke medewerker”

Instructie 3: Zonder premiumprofiel: Als de klant aangeeft geen premiumprofiel te hebben, antwoord je: "Je kunt je foto niet aanpassen. Als je wilt, kan ik je in contact brengen met een menselijke medewerker."

Instructie 4: Als het niet duidelijk is welk profiel de klant heeft, antwoord je: "Ik heb niet begrepen wat je profieltype is."

Wat je wel kunt doen

Gebruik in plaats van dit soort gedetailleerde instructies meer flexibele richtlijnen voor de agent. Overweeg de volgende best practices:

1. Gebruik RAG-/kennisacties voor beleid en regels die in knowledge-base-artikelen staan (in plaats van ze als instructies te omschrijven). De relevante informatie wordt dan op het juiste moment opgehaald. Voor het bovenstaande voorbeeld betekent dit dat in een knowledge-base-artikel met de titel 'Foto aanpassen' het volgende moet staan: "Alleen kandidaten met een premiumprofiel waarvan het contract voorziet in het aanpassen van foto's kunnen hun foto aanpassen".
2. Schets de belangrijkste richtlijnen en vangrails afzonderlijk, onafhankelijk van het gesprek. Geef agents een duidelijke en beknopte uitleg van het verwachte gedrag of de verwachte procedure.

Op basis van deze best practices kan een betere set instructies er als volgt uitzien:

Instructie 1 : "Gebruik knowledge-base-acties om het beleid te controleren bij verzoeken om accountaanpassingen".

Instructie 2 : "Beantwoord geen vragen waarvoor geen toepasselijk beleid kon worden gevonden".

Het toepassen van de bovenstaande richtlijnen kan de resultaten van agents verbeteren. Als de klant de agent nu om een profielaanpassing vraagt, zal de agent begrijpen dat hij het vereiste beleid uit de knowledge base moet ophalen, de opgehaalde regels moet interpreteren, deze regels moet toepassen op de context en ten slotte op de klant moet reageren. In tegenstelling tot de te gedetailleerde beschrijvingen is deze gedragsaanpak veel algemener en breder toepasbaar. Als je niet elk mogelijk gesprek helemaal uitschrijft, kan de agent flexibel reageren met het gewenste gedrag op een breder scala aan gespreksonderwerpen.

Dwing een actiereeks af (niet van toepassing op Agent Script)

De observatietaakaanwijzing bevat instructies en actiebeschrijvingen, maar zonder een gedefinieerde volgorde. Als de volgorde van acties van groot belang is, moet deze volgorde expliciet in dezelfde instructie worden vermeld. Met Agent Script kunnen we een volgorde van uitvoeringen afdwingen met behulp van de overgangen. Dit wordt verder uitgelegd in hoofdstuk 6.

Laten we verder gaan met het voorbeeld van agents op een wervingswebsite. De agent moet in staat zijn om sollicitatiegesprekken met de juiste recruiters te plannen. Hiertoe moet de agent eerst de beschikbaarheid van de recruiters controleren en vervolgens drie mogelijke tijdstippen voorstellen aan de kandidaat.

Om de volgorde van uitvoering te garanderen, mogen de instructies in dit geval niet in aparte segmenten staan:

1. Instructie 1: Controleer de beschikbaarheid van recruiters.
2. Instructie 2: Stel vervolgens passende tijdstippen voor aan de kandidaat.

Deze instructies werken niet omdat de redeneringsengine niet weet waar de term 'vervolgens' in instructie 2 naar verwijst. Dit komt doordat de instructies als groep naar de redeneringsengine worden gestuurd en niet in een bepaalde volgorde.

In plaats daarvan moeten sequentiedefiniërende instructies worden samengevoegd tot één omschrijving:

1. Instructie 1: Controleer de beschikbaarheid van recruiters. Stel vervolgens passende tijdstippen voor aan de kandidaat.

Dwing een actie-output af zonder te herschrijven

De redeneringsengine is zelf een LLM. Hij is verantwoordelijk voor het genereren van het definitieve antwoord op basis van de agentische lus. De aanpak is nodig om agent-instructies af te dwingen die vangrails bieden voor het genereren van antwoorden, of om te komen tot gecombineerde outputs van meerdere acties die deel uitmaakten van de agentische lus. Dit is noodzakelijk om aan het gebruikersverzoek te voldoen.

Wanneer echter wordt verwacht dat er slechts één taakaanwijzingsactie is uitgevoerd, kan een instructie worden geïmplementeerd om de agent te instrueren om nooit de output van een actie te wijzigen. Dit zorgt voor voorspelbaarder en betrouwbaarder agentisch gedrag.

Het afdwingen van deze strikte gebondenheid aan goedgekeurde taakaanwijzingssjablonen is van cruciaal belang in bepaalde scenario's, vooral wanneer consistentie, naleving en vooraf gedefinieerde berichten belangrijk zijn. Dit zijn twee voorbeelden:

• Gereguleerde sectoren: Organisaties die actief zijn in sterk gereguleerde sectoren (zoals de financiële sector, de gezondheidszorg of de juridische sector) hebben vaak strikte controle nodig over alle klantgerichte communicatie. Goedgekeurde taakaanwijzingssjablonen zorgen ervoor dat antwoorden voldoen aan wetten en regelgeving, waardoor het risico op verkeerde interpretatie, aansprakelijkheid of verspreiding van onnauwkeurige informatie wordt geminimaliseerd.
• Vooraf geteste en gevalideerde antwoorden: Wanneer taakaanwijzingssjablonen strenge tests en validatie hebben ondergaan om nauwkeurigheid, effectiviteit en gewenste resultaten te garanderen. Het afwijken van deze templates kan hun effectiviteit en waarde ondermijnen. Strikte naleving garandeert dat de beproefde boodschap consistent wordt geleverd.

Deze instructie beperkt de vrijheid van de agent om de output van acties te wijzigen. Zorg ervoor dat de instructie verwijst naar de output van de taakaanwijzingssjabloon (bijvoorbeeld 'promptResponse'), zoals getoond in deze Plantracker.

De instructie in dit geval kan dus zijn:

“ Wijzig de output promptResponse niet, ongeacht het kanaal van de agent. ”

Beperkingen bij het afdwingen van strikte naleving:

Wanneer een interactie meerdere afzonderlijke agent-acties vereist, is het niet mogelijk om de strikte naleving van één template af te dwingen. In dit scenario moet de redeneringsengine deze acties samenvoegen tot één reactie en dus elke afzonderlijke actie-output aanpassen.

Optimaal aantal instructies

Op basis van algemene LLM-eigenschappen ligt het ideale aantal instructies tussen 5 en 10, afhankelijk van de complexiteit van de instructie en de interactie met de instructie. Deze instructie-eigenschappen beïnvloeden het aantal instructies dat de redeneringsengine kan volgen:

• Duidelijkheid en specificiteit: Goed gedefinieerde regels zijn gemakkelijker te volgen.
• Conflicten tussen regels: Als regels elkaar tegenspreken, is extra logica nodig om ze op te lossen.
• Lengte en complexiteit: Als elke regel diepgaand moet worden beredeneerd, overweeg dan om de regels op te splitsen in kleinere instructies.

Als het erg belangrijk is om een instructie expliciet op te volgen, voeg dan termen toe die hun belang onderstrepen:

• Urgentie en belang (onmiddellijk, dringend, kritiek, essentieel, verplicht)
• Autoriteit en handhaving (vereist, verplicht, strikt gehandhaafd)
• Gevolgen en waarschuwingen (overtreding zal leiden tot, niet-naleving zal leiden tot, niet-naleving kan resulteren in, strikte sancties zijn van toepassing, zero tolerance)
• Duidelijkheid en directheid (moet, illegaal, verboden, niet toegestaan, altijd/nooit)

Door antwoorden te baseren op data, wordt de betrouwbaarheid van en het vertrouwen in agents aanzienlijk verbeterd. Deze antwoorden zijn gebaseerd op feitelijke informatie in plaats van op speculatie of verouderde kennis. Retrieval Augmented Generation (RAG) is een algemeen aanvaarde techniek die een agent in staat stelt toegang te krijgen tot een kennisbank en deze te gebruiken om nauwkeurigere en contextueel relevantere antwoorden te formuleren. Op basis van de vraag van een gebruiker maakt een agent gebruik van RAG om relevante informatie op te halen uit toepasselijke databronnen en vult de taakaanwijzing vervolgens aan met deze informatie voordat deze naar de LLM wordt verzonden. Een agent die RAG gebruikt, levert agentinteracties met hogere kwaliteit, nauwkeurigheid en algehele bruikbaarheid, wat het vertrouwen en de tevredenheid van de gebruiker verhoogt. Best practices voor RAG worden uitgebreid beschreven in een openbaar beschikbare whitepaper genaamd Agentforce en RAG: best practices voor betere agents.

Kennis versus instructies

Het maken van onderscheid tussen kennis en instructies is belangrijk voor het vinden van de juiste balans tussen sturing en flexibiliteit, omdat ze verschillende doelen hebben:

• Kennis: Beschouw kennis als de bibliotheek met boeken waartoe de agent toegang heeft tijdens het genereren van antwoorden. Voorbeelden zijn onder meer documenten, knowledge-base-artikelen en whitepapers. Bedenk dat dit ook beleidsregels en algemene bedrijfsregels kunnen zijn. Kennis kan ook verwijzen naar transactionele bestanden, zoals e-mails, gesprekstranscripties en zelfs de geschiedenis van (agent)gesprekken. Tot slot omvat kennis lange tekstvelden in gestructureerde data. Kennis komt meestal via RAG bij de agent terecht.
• Instructies: Beschouw instructies als de minimale set regels die de agent duidelijk maken wanneer elke actie moet worden toegepast. Instructies kunnen ook grenzen bepalen voor het hele gesprek, zoals de vereiste toon van het gesprek. Vaak kunnen instructies beknopter en flexibeler worden gemaakt, zonder dat dit ten koste gaat van de duidelijkheid of intentie. In plaats van een rigide script met specifieke antwoorden te geven voor elk mogelijk klantscenario, kan worden overwogen om algemene richtlijnen en principes te implementeren die de agent helpen de juiste actie(s) te selecteren in verschillende situaties.

Retrieval Augmented Generation (RAG)

Retrieval Augmented Generation (RAG) fungeert als een slimme datalaag voor kennis. Hiermee hebben agents toegang tot informatie in verschillende formats en beschikken ze over relevante tekstfragmenten voor het beantwoorden van vragen. Met RAG kunnen agents nauwkeurigere LLM-antwoorden krijgen zonder de LLM-taakaanwijzing te overspoelen met externe inhoud of het contextvenster te overschrijden.

Wanneer RAG wordt uitgevoerd, doorloopt het drie stappen:

1. Ophalen: Het AI-systeem doorzoekt een grote database of kennisbron om relevante informatie te verzamelen voor de LLM-taakaanwijzing. Dit wordt gedaan met behulp van semantisch zoeken, een geavanceerdere techniek dan traditionele zoekopdrachten op basis van trefwoorden. In tegenstelling tot zoeken op trefwoord, waarbij exacte termen moeten worden gevonden, wordt bij semantisch zoeken gekeken naar de betekenis of context achter de woorden. Het identificeert relevante informatie op basis van de concepten of relaties tussen termen, in plaats van alleen te zoeken naar exacte woordovereenkomsten. Zoeken op trefwoord kan ook een rol spelen in dit ophaalproces, waardoor de semantische zoekopdracht wordt uitgebreid met trefwoordvergelijking voor specifieke terminologie of namen. Dit type zoekactie wordt hybride zoeken genoemd.
2. Augmenteren: De opgehaalde informatie wordt toegevoegd aan de taakaanwijzing.
3. Genereren: Het LLM genereert een contextueel passende en nauwkeurigere reactie dankzij de taakaanwijzing die is aangevuld met opgehaalde kennis.

In Agentforce kan RAG worden gebruikt met of zonder een taakaanwijzingssjabloon:

1. Taakaanwijzinggebaseerde RAG: Bij deze aanpak staan de instructies die aangeven hoe het antwoord moet worden gegenereerd in de taakaanwijzingsinstructies in een taakaanwijzingssjabloon. In dit geval hangt het antwoord volledig af van wat het LLM genereert. Afgezien van de taakaanwijzingsinstructies kan de beantwoording worden beïnvloed, zoals LLM-configuratie-instellingen in Einstein Studio, maar het resultaat is nog steeds niet deterministisch.
2. Redeneringsengine-gebaseerde RAG: In plaats van een taakaanwijzingssjabloon te gebruiken, gebruikt de agent een actie die stukjes data ophaalt (via een stroom of Apex-klasse) en deze opslaat in een variabele (zie de volgende sectie). Bij deze aanpak genereert de redeneringsengine (en dus niet het LLM) rechtstreeks antwoorden, gebaseerd op de opgehaalde data. De instructies die het genereren van antwoorden bepalen, zijn agent-instructies in plaats van taakaanwijzingssjabloon-instructies. De variabele die de opgehaalde inhoud bevat, kan nog steeds expliciet worden doorgegeven als invoer voor een actie. Het kan ook aan de redeneringsengine worden doorgegeven door deze toegang te verlenen tot de inhoud van de variabele. Deze aanpak heeft echter enkele nadelen. Er bestaat een risico dat de redeneringsengine wordt overspoeld door inhoud en verantwoordelijkheden. In tegenstelling tot een taakaanwijzing zijn de parameters van het redeneringsengine-LLM bovendien niet configureerbaar. Aan de andere kant kan de redeneringsengine een antwoord genereren met behulp van zowel de opgehaalde stukjes data als de geschiedenis van het gesprek.

De aanbevolen methode is optie 1. Deze vermindert het aantal taken dat de redeneringsengine moet uitvoeren en verbetert zo de antwoordkwaliteit. In het volgende gedeelte wordt een uitzondering op deze regel besproken, waarbij de inhoud tijdens het gesprek wordt vastgehouden en expliciet wordt doorgegeven aan een actie.

Best practices voor RAG

• Vermijd gescripte RAG-instructies: In plaats van instructies rechtstreeks te koppelen aan specifieke artikelen voor bepaalde vragen, maak je gebruik van de intelligentie van RAG om dynamisch de meest relevante databron en het meest nauwkeurige tekstfragment te vinden. Het matchingproces van RAG is gebaseerd op een breder begrip van de vraag, niet alleen op het exact volgen van het traject van vraag naar bron.
• Consolideer onderwerpen: Groepeer gerelateerde vraagcategorieën in één onderwerp. RAG kan effectief relevante antwoorden identificeren op basis van het vraagtype, zelfs binnen een breder onderwerp. Problemen met producten op het gebied van onderhoud of batterijproblemen kunnen bijvoorbeeld worden samengevoegd tot één omvattender onderwerp.
• Sla RAG-output op in een variabele: Wanneer het aantal interactielimieten kan worden bereikt, sla je de RAG-output op in een variabele. Dit houdt de informatie toegankelijk voor het richting geven aan interacties van agents buiten de standaarddrempel. Een voorbeeld hiervan zal in de volgende paragraaf worden gegeven.

Bepaalde bedrijfsprocessen vereisen een nog voorspelbaardere uitvoering, zoals het afdwingen van een specifieke actiereeks of voorwaarden voor het activeren van acties of onderwerpen.

Om dit deterministische gedrag te bereiken, kunnen variabelen worden gebruikt. Variabelen functioneren als een gestructureerde vorm van het kortetermijngeheugen van een agent, dat kan dienen als actie-input of -output. Bovendien kan de status van een variabele de activering van specifieke onderwerpen en acties bepalen.

Manieren waarop variabelen determinisme ondersteunen

Variabelen kunnen op de volgende manieren bijdragen aan gestuurd determinisme van agents:

1. Persistente dynamische grounding: Variabelen stellen agents in staat om hun begrip van de wereld voortdurend bij te werken en tegelijkertijd belangrijke informatie te bewaren die niet wordt beïnvloed door latere interacties. Deze methode zorgt ervoor dat kritieke informatie (wat ongestructureerde data die via RAG is opgehaald kan zijn, maar ook gestructureerde data zoals informatie over gebruikersprofielen) gedurende het hele gesprek blijft behouden, onafhankelijk van de gesprekslengte.
2. Actie-input/-output: Variabelen kunnen worden gebruikt als zowel input als output voor acties. De actie verwijst expliciet naar variabelen en de uitvoering van de actie is niet afhankelijk van de redeneringsengine voor het instellen van deze input en output, wat het determinisme van de agent vergroot.
3. Filteren: Variabelen kunnen worden gebruikt om de voorwaardelijke uitvoering van acties of onderwerpen te bepalen. Variabelen zorgen voor een specifieke informatiestroom tussen acties en determinisme in de uitvoering van acties. Deze mogelijkheid is met name cruciaal voor beveiligingsregels waarbij acties niet kunnen worden gestart als specifieke input-variabelen, zoals e-mail, niet zijn geverifieerd.

Soorten variabelen in Agentforce

Agentforce heeft twee soorten variabelen:

• Contextvariabelen zijn door het systeem gegenereerde variabelen met informatie over de gebruiker en de gesprekssessies.
• Aangepaste variabelen kunnen door de gebruiker worden geïnstantieerd. Ze bevatten alle soorten informatie die worden gebruikt voor een van de drie manieren waarop variabelen determinisme ondersteunen.

Variabeletypen ondersteunen de volgende mogelijkheden:

Laten we variabelen eens nader bekijken aan de hand van een voorbeeld van een use case: een klantgerichte probleemoplossingsagent. In dit voorbeeld worden variabelen gebruikt voor alle drie de doeleinden: persistente dynamische grounding, actie-input/-output en filteren.

In dit voorbeeld helpt de agent een klant bij het oplossen van een technisch probleem met een apparaat. Probleemoplossing omvat meestal het doorlopen van een aantal stappen. De agent moet een klantenservice-ervaring bieden die het werk van een menselijke medewerker nabootst. Om dit te doen, moet de agent niet alle stappen voor probleemoplossing gelijktijdig aan de klant verstrekken. In plaats daarvan moet hij stap-voor-stap instructies bieden, samen met de mogelijkheid om tussen stappen te navigeren (zoals teruggaan naar eerder behandelde stappen) op basis van de reactie van de klant.

Een uitdaging hierbij is het vermogen van de agent om alle stappen voor probleemoplossing tijdens het gesprek te onthouden. Met het oog op het beperkte geheugen van de agent vanwege het beperkte aantal interacties dat deze kan opslaan, kunnen deze stappen voor de redeneringsengine uit de context worden verwijderd als het gesprek te lang wordt.

Je pakt dit aan door een variabele te gebruiken om de redeneringsengine dynamisch te grounden in stappen voor de probleemoplossing. Door de informatie op te halen en op te slaan in een variabele, blijft deze tijdens het gesprek beschikbaar en kan deze worden bijgewerkt. De redeneringsengine gebruikt de informatie die in deze variabele is opgeslagen voor dynamische grounding.

In dit voorbeeld bevat een onderwerp twee acties. Deze twee acties zijn nodig om een consistente datastroom in stand te houden. De eerste actie wordt gebruikt voor het vullen van de variabele met alle stappen voor de probleemoplossing. De tweede actie maakt gebruik van die variabele tijdens het oplossen van het probleem zelf.

1. Actie 1: "Oplossingsstappen toevoegen". Dit is de eerste actie, die wordt geactiveerd als de agent voor het eerst wordt geconfronteerd met het probleem. Het maakt gebruik van Retrieval Augmented Generation om alle benodigde oplossingsstappen uit een geïndexeerde knowledge base te halen. De actie slaat de resulterende output op in een variabele met de naam 'Oplossingsstappen'.
2. Actie 2: "Gebruiken tijdens het oplossen van een probleem". Dit is een actie op basis van een taakaanwijzing die de meest waarschijnlijke volgende stap voor probleemoplossing uitvoert en die tijdens het probleemoplossingsproces moet worden gebruikt. De agent krijgt de instructie om deze actie te gebruiken terwijl hij bezig is met het oplossen van een probleem.

De oorspronkelijke vraag van de klant is de input voor beide acties. De tweede actie heeft een andere input: de inhoud van de variabele 'Oplossingsstappen'. Deze variabele is ingesteld door de eerste actie. Bedenk dat de tweede actie de stappen voor probleemoplossing niet zelf ophaalt, maar ze ontvangt als input van de eerste actie via de variabele. Het volgende diagram toont de datastroom tussen deze twee acties.

De actie 'Gebruiken tijdens het oplossen van een probleem' verwijst altijd naar de oorspronkelijke stappen voor probleemoplossing die zijn opgehaald door de actie 'Oplossingsstappen toevoegen'. Deze datastroom zorgt ervoor dat probleemoplossingsstappen coherent worden bewaard en altijd aanwezig zijn, ongeacht de gespreksduur.

Om de acties uit te voeren die in dit voorbeeld zijn gedefinieerd, zijn specifieke instructies nodig, zoals 'Altijd eerst 'oplossingsstappen invullen' uitvoeren.' Gezien echter de niet-deterministische aard van LLM's die door agents worden gebruikt, kan dit in bepaalde gevallen leiden tot een andere volgorde. Om een deterministische volgorde van uitvoering te garanderen, passen we voorwaardelijke filters toe op deze variabelen om de juiste actievolgorde af te dwingen. De agent leest de waarde van de variabele 'Oplossingsstappen' en definieert twee filters op basis van de vraag of deze variabele een waarde heeft of niet.

• De actie 'Oplossingsstappen toevoegen' kan alleen worden uitgevoerd als de variabele 'Oplossingsstappen' leeg is.
• 'Gebruiken tijdens het oplossen van een probleem' kan alleen worden uitgevoerd als de variabele 'Oplossingsstappen' is gevuld.

Deze voorwaardelijke filters forceren nu de volgorde van uitvoering van acties deterministisch: 'Gebruiken tijdens het oplossen van een probleem' moet wachten tot 'Oplossingsstappen toevoegen' zijn werk heeft voltooid, waardoor wordt gegarandeerd dat de variabele 'Oplossingsstappen' altijd een waarde heeft.

Om ervoor te zorgen dat de actie correct wordt uitgevoerd, is een derde actie nodig om de variabele 'Oplossingsstappen' opnieuw in te stellen als het probleem volledig is opgelost. Als gevolg hiervan wordt de agent opnieuw ingesteld op de vereiste status om te helpen bij een mogelijk nieuw, ander probleem. Deze derde actie heet 'Oplossingsvariabele leegmaken'. Het volledige actieschema is hieronder afgebeeld.

Variabelen zijn cruciaal om onze agent in staat te stellen problemen van klanten op te lossen door het volgende mogelijk te maken:

• Persistente dynamische grounding:: Variabelen slaan stappen voor probleemoplossing op, zodat ze tijdens het gesprek beschikbaar zijn, ongeacht de lengte of het aantal interacties. Dit voorkomt dat de agent context vergeet.
• Datastroom: Variabelen vergemakkelijken de datastroom tussen acties. De variabele 'Oplossingsstappen' slaat bijvoorbeeld de opgehaalde stappen voor probleemoplossing op uit de actie 'Oplossingsstappen toevoegen' en geeft deze als input voor de actie 'Gebruiken tijdens het oplossen van een probleem'.
• Determinisme: Variabelen kunnen worden gebruikt als filters om een specifieke volgorde van uitvoering van acties af te dwingen. De actie 'Gebruiken tijdens het oplossen van een probleem' wordt bijvoorbeeld alleen uitgevoerd als de variabele 'Oplossingsstappen' Step is gevuld, zodat de actie 'Oplossingsstappen toevoegen' eerst moet worden uitgevoerd.

In het tijdperk van generatieve AI blijft voorspellende AI van cruciaal belang omdat hiermee de fundamentele informatie wordt verzameld die genererende capaciteit aanstuurt, verbetert en contextualiseert. Terwijl generatieve AI zich richt op het creëren van nieuwe inhoud, zoals tekst, afbeeldingen of video's, maken voorspellende modellen voorspellingen over de toekomst op basis van input van realtime bedrijfsdata. Voorbeelden van bedrijfsresultaten zijn onder meer de waarschijnlijkheid van klantverloop, conversiewaarschijnlijkheden, kans op escalatie van cases, customer lifetime value en case-classificatie. Voorspellingen helpen met anticiperen op de behoeften van gebruikers, het personaliseren van output, het nemen van beslissingen en het in realtime optimaliseren van de relevantie van content - allemaal door trends en cijfers te analyseren. In toepassingen zoals gepersonaliseerd leren, gezondheidszorg of financiële planning zorgt voorspellende AI er bijvoorbeeld voor dat generatieve output aansluit bij individuele contexten en waarschijnlijke toekomstige scenario's. Samen zorgen voorspellende en generatieve AI voor een krachtige synergie, waarbij vooruitziendheid wordt gecombineerd met creativiteit om meer intelligente, adaptieve en impactvolle technologieoplossingen te stimuleren.

De output van voorspellende modellen integreren in workflows van agents

Om voorspellende modeloutput op te nemen in agentworkflows, voeg je gewoon voorspellende modelacties toe aan de Agentforce-activa. Model Builder biedt de middelen om voorspellende modellen te bouwen of te registreren (BYO). Deze modellen worden vervolgens door de agent gebruikt om voorspellingen te doen. De resulterende voorspellingen (evenals de voorspellers) kunnen worden opgeslagen in aangepaste variabelen. Agents kunnen deze variabele waarden gebruiken als input voor en het conditionaliseren van de uitvoering van specifieke acties en onderwerpen.

Voorbeelden van use cases die zijn geïntegreerd met voorspellende modellen

• Segmentatie: Voer classificatie met meerdere klassen uit voor klantsegmentatie en gebruik het resulterende segment om bepaalde acties te filteren. Reserveer bijvoorbeeld premium acties voor premium-klanten.
• Kans op escalatie: Voorspel de kans op escalatie voor een servicecase. Als deze kans een bepaalde drempel overschrijdt, sta dan de uitvoering toe van acties die de case sneller oplossen of sneller escaleren naar menselijke medewerkers.
• CPG: Plan een promotie alleen als de toename in sales (score berekend door een voorspellend model) een bepaalde drempel overschrijdt.
• Commerce: Stel alleen een product voor als de koopbereidheid een bepaalde drempel overschrijdt.

Bepaalde bedrijfsprocessen moeten in een nauwkeurige volgorde worden uitgevoerd en vereisen geen gebruikersinvoer tijdens de uitvoering. In dit geval kan een vooraf bepaalde stappenstroom worden afgedwongen via stromen, API's of Apex. Als je een bestaande stroom hebt waarop in de productie wordt vertrouwd, is dit een goede indicatie dat deze door de agent kan worden bewaard en gebruikt voor de uitvoering van dat bedrijfsproces. Alle volgende voorbeelden bevatten vooraf bepaalde stappenreeksen die de agent kan uitvoeren zonder gebruikersinvoer. Het agentische gedrag bestaat in dit geval uit het identificeren van welk deterministisch proces moet worden uitgevoerd, hoe de nodige input moet worden verzameld en hoe de outputs moeten worden geïnterpreteerd en verwerkt.

Bedrijfsprocessen met veel opeenvolgende stappen (meer dan drie, als vuistregel) en veel afhankelijkheden van variabelen worden te complex en omslachtig om af te dwingen met instructies. In dit geval is het mogelijk om ze gewoon te programmeren in hardcode met behulp van de deterministische actietypen die in dit gedeelte worden vermeld. Merk ten slotte op dat deze implementaties niet-deterministische elementen kunnen bevatten, zoals het aanroepen van LLM's met opgeloste taakaanwijzingssjablonen. Daarom zijn ze end-to-end niet altijd volledig deterministisch en kunnen ze nog steeds de gewenste flexibiliteit laten zien waar agents om bekend staan.

De volgorde van stappen in een marketingtraject wordt bepaald door vaste regels en is niet afhankelijk van conversational gebruikersinput. Daarom kan de stroom als een Agentforce-actie worden gebruikt. Een aanroepbare actie kan worden gemaakt om achtergrond- of gebeurtenisgestuurde taken uit te voeren vanuit een oplossingscomponent die een stroom of Apex-klasse kan aanroepen. Voeg een aanroepbare actie toe aan een stroom of Apex-klasse en geef de taak op die de agent moet voltooien, evenals de voorwaarden die de agent activeren. Aanroepbare acties kunnen ook de contextvariabelen van de agent bevatten en belangrijke informatie doorgeven.

Salesforce-stromen kunnen worden gebruikt om routinetaken te automatiseren, zoals het maken van vervolgtaken, het verzenden van herinneringse-mails of het bijwerken van records. Stromen maken het werk efficiënter en productiever. Agents kunnen ook stromen uitvoeren met behulp van stroomacties. Vanwege hun determinisme zijn stromen een geweldige manier om agentisch gedrag te sturen wanneer een bedrijfsproces in een bepaalde volgorde moet worden uitgevoerd. Een goede indicatie dat een stroomactie de voorkeur heeft, is wanneer het onderwerp anders instructies zou bevatten zoals "eerst dit doen, dan dit doen en uiteindelijk dit doen". Het afdwingen van reeksen van meer dan drie stappen wordt lastig om te beheren via instructies en variabelen.

Stromen kunnen ook niet-deterministische elementen bevatten door taakaanwijzingen aan te roepen. Een taakaanwijzingsknooppunt in de stroom roept een taakaanwijzingssjabloon aan en verzamelt het antwoord dat kan worden doorgegeven aan andere elementen in de stroom. Deze verdere elementen kunnen ook weer taakaanwijzingsknooppunten zijn, bijvoorbeeld het samenvatten van het vorige antwoord. Zo ontstaat een keten van taakaanwijzingen. Dit is vooral handig wanneer de regels voor taakaanwijzingsketens worden gedefinieerd door vaste elementen en niet afhankelijk zijn van gebruikersinput. Een voorbeeld is agentische RAG, waarin een vooraf gedefinieerde reeks retrievers of taakaanwijzingen in een stroom toegang heeft tot specifieke databronnen in een bepaalde volgorde. Denk daarbij aan het eerst ophalen van data uit het landdocument van een gebruiker, om vervolgens naar behoefte andere bronnen te raadplegen. Dit ketenmechanisme dwingt een betrouwbare en geordende extractie van relevante informatie af.

Net als flows zijn Apex- en API-acties deterministisch, omdat een vooraf gedefinieerde reeks acties kan worden gecodeerd. Deze acties kunnen niet-deterministische elementen bevatten, zoals het aanroepen van taakaanwijzingssjablonen of LLM-aanroepen. Per definitie voeren ze deze stappen echter deterministisch uit, wat de agentische variabiliteit vermindert door de actie op het juiste moment aan te roepen, de benodigde input te verzamelen en de output te verwerken. Deze verantwoordelijkheden moeten nog steeds worden beheerd door agentische instructies, dus zijn ze niet-deterministisch. Apex- en API-acties zijn het pro-code-equivalent van stroomacties.

Van probabilistisch naar deterministisch redeneren

In de determinisme-niveaus 1 tot en met 5 voegden we geleidelijk structuur toe aan de omgeving van de agent. We definieerden wat het kon doen (niveau 1, onderwerpen), legden vervolgens uit hoe het zich moest gedragen (niveau 2, instructies), baseerden het op de feiten (niveau 3, data), beheerden de status (niveau 4, variabelen) en gaven het rigide tools (niveau 5, deterministische acties). De centrale besluitvormingsengine bleef echter fundamenteel probabilistisch. De redeneringsengine moest nog steeds zelf beslissen welke tool moest worden gekozen of welke vervolgvraag moest worden gesteld. Voor deze beslissingen vertrouwden we volledig op het grote taalmodel (LLM).

Op niveau 6 (Agent Script) verandert deze architectuur fundamenteel. Nu heb je de mogelijkheid om het redeneringsproces zelf te programmeren.

Met Agent Script geven we het model niet langer taakaanwijzingen, maar worden er scripts uitgevoerd voor de agent. Dat wil niet zeggen dat we teruggaan naar de rigide, ouderwetse chatbots. Liever noemen we dit hybride redeneren. Het stelt je in staat om de creatieve, conversationele kracht van het LLM toe te voegen aan lagen van onveranderlijke, deterministische logica. Je definieert expliciet het kritieke pad van de uitvoering (de 'must-do's'), maar geeft het LLM de specifieke vrijheid om natuurlijke taal te begrijpen en reacties te genereren.

Bij het ontwerpen van workflows is het van essentieel belang om het gebruik van LLM-gebaseerde agents met scripts te vermijden en de deterministische logica alleen te vervangen als de volgende stappen al duidelijk en onveranderlijk zijn. Als een proces een voorspelbaar pad volgt zonder dat er complexe redenering nodig is om vervolgacties te decoderen, voegt het introduceren van een generatief model onnodige latentie, kosten en een foutenmarge toe. Traditionele programmatische stromen blijven de voorkeur hebben voor processen die puur deterministisch zijn en geen redenering nodig hebben. Eenvoudige routering of lineaire overgangen kunnen worden afgehandeld door een normale procedurele stroom. Het gebruik van een LLM is in dit geval over-engineering en brengt de betrouwbaarheid van het systeem in gevaar.

Als vuistregel moeten agentische oplossingen worden overwogen als het systeem te maken krijgt met ongestructureerde input die moet worden gesynthetiseerd uit verschillende en zeer gevarieerde bronnen (eventueel ook input uit gesprekken) voordat een beslissing kan worden genomen.

Maar hoe bereik je dit niveau van controle? Er zijn twee verschillende paden voor de zakelijke architect en de pro-code developer.

Om determinisme van niveau 6 naar je agent te brengen, is het niet strikt noodzakelijk om code te schrijven. Salesforce biedt twee modaliteiten om het onderliggende Agent Script te genereren, wat de toegang tot deterministisch redeneren democratiseert.

Voor bedrijfsanalisten, beheerders en low-code gebruikers is niveau 6 rechtstreeks toegankelijk in de Agent Builder.

We hebben een canvas in documentstijl geïntroduceerd dat dient als een tekst-naar-script-interface. In plaats van code te schrijven, formuleer je de logica van het onderwerp in gestructureerde, natuurlijke taal. De Builder interpreteert vervolgens je intentie en compileert deze in Agent Script op de achtergrond.

• Je schrijft: "Controleer eerst of de bestelling ouder is dan 30 dagen. Als dit het geval is, vertel de gebruiker dan dat we geen retourzendingen kunnen accepteren en beëindig het gesprek beleefd. Als dit niet het geval is, vraag dan naar de staat van het artikel."
• Het systeem compileert deze informatie in natuurlijke taal automatisch in de benodigde if/else-structuren, variabele controles en end_conversation-opdrachten.

Hierdoor kun je de logica in natuurlijke taal schrijven en deze door het platform in code laten omzetten, zodat zelfs niet-programmeurs rigide vangrails en determinisme kunnen afdwingen.

Developers die maximale precisie willen, kunnen Agent Script ook zelf rechtstreeks in Agent Builder schrijven. De developer kan het onderliggende script van het canvas met de informatie in natuurlijke taal zichtbaar maken, zodat deze het script rechtstreeks kan coderen. Deze aanpak maakt zelfs een hybride authoring-ervaring mogelijk: sommige instructies worden in natuurlijke taal op het canvas geschreven, terwijl andere rechtstreeks worden gescript (of gewijzigd) met behulp van code. Als je schakelt tussen deze twee omgevingen, zie je dat de twee modaliteiten altijd perfect op elkaar zijn afgestemd.

Beide modaliteiten benutten het volledige potentieel van niveau 6:

• Gedetailleerde tracering: je kunt de scriptuitvoering doornemen om precies te zien waar variabelen zijn gewijzigd of vertakkingen zijn genomen.
• Complexe lusverwerking: beheer geavanceerde retry-logica en statuswijzigingen met meerdere variabelen die moeilijk te beschrijven zijn in natuurlijke taal.
• Versiebeheer: behandel agentisch gedrag als code, compatibel met git- en CI/CD-pipelines voor het beheer van agentversies.

Of je nu Agent Script genereert via de Builder of deze handmatig schrijft, het leidt altijd tot dezelfde output: Agent Script wordt geconverteerd tot een agentschema dat wordt uitgevoerd door de Atlas Reasoning Engine.

Om niveau 6 te beheersen, moet je weten wat er onder de motorkap gebeurt. Agent Script beheert het gedrag via specifieke programmatische structuren binnen redeneringsblokken. In tegenstelling tot standaard taakaanwijzingen (suggesties die het LLM kan volgen) zijn dit opdrachten die hoe dan ook worden uitgevoerd. Dat kan voor, tijdens of na het redeneringsproces zijn, en ze kunnen verschillende vormen van determinisme hebben. We bekijken eerst een paar algemene patronen en geven enkele eenvoudige voorbeelden. Vervolgens illustreren we dit met voorbeelden van architectonische blauwdrukken van gescripte agents.

Op niveau 1-5 hoopten we dat de agent voor of na een bepaalde stap in het proces iets zou doen (een actie uitvoeren). Op niveau 6 dwingen we de agent hiertoe. Alles wat er staat geschreven in de blokken before_reasoning en after_reasoning zal altijd worden uitgevoerd, respectievelijk voor en na het aanroepen van het LLM om te redeneren op basis van instructies. Dit kan het uitvoeren van andere acties zijn, maar ook de overgang naar onderwerpen, het instellen van variabelen, enzovoort.

Door bijvoorbeeld de opdracht 'run' te gebruiken in de before_reasoning-instructies van een onderwerp, kun je een actie uitvoeren zelfs voordat het LLM wordt aangeroepen om een antwoord te genereren. Dit garandeert dat de data direct beschikbaar is, wat redeneringslatentie voorkomt en waardoor de agent nooit kan vergeten om de tool aan te roepen.

De scriptstructuur:

Met voorwaardelijk determinisme kun je standaard programmeerlogica gebruiken om de stroom te beheren. Dit is van cruciaal belang voor nalevingsworkflows waarbij je stappen niet mag overslaan of aanpassen.

De scriptstructuur:

In dit voorbeeld krijgt het LLM nooit de optie om een goedkeuring voor een niet-VIP-gebruiker te hallucineren. De aftakking wordt deterministisch bepaald door de engine.

Een andere krachtige beheerfunctie is de mogelijkheid om de agent te dwingen van het huidige onderwerp over te gaan naar een ander onderwerp. Dit voorkomt dat de agent vast komt te zitten of in een niet-gerelateerd gesprek terechtkomt.

De scriptstructuur:

Deze overgang is geen suggestie. Het is een vaststaande omleiding van de uitvoeringsstroom die afhangt van de waarde van een variabele. Hoewel de omleiding vaststaat en niet onderhandelbaar is, vindt er opnieuw een normaal redeneringsproces plaats binnen het onderwerp waartoe de agent nu wordt gedwongen.

Bovendien kun je met Agent Script direct na voltooiing expliciet een overgang van de ene actie naar de volgende forceren. Deze functionaliteit zorgt ervoor dat de agent een rigide, deterministische stroom volgt in plaats van bij elke stap te vertrouwen op probabilistische of autonome besluitvorming. Door deze acties in een vooraf gedefinieerde reeks aan elkaar te koppelen, garandeer je dat specifieke taken in een exacte volgorde worden uitgevoerd. Zo heb je de volledige controle over de logica en het agentische gedrag.

Agent Script geeft je directe lees- en schrijftoegang tot het kortetermijngeheugen (variabelen) van de agent. Je kunt variabelen specifiek instellen op basis van actie-output. Dit voorkomt een gebrekkige doorgifte waarbij een LLM de JSON-output van een tool verkeerd interpreteert.

De scriptstructuur:

Om de kracht van Agent Script echt te begrijpen, moeten we verder kijken dan individuele commando's en ze gezamenlijk observeren. De volgende architecturale patronen (afgeleid van onze verzameling Agent Script-recepten ) laten zien hoe determinisme van niveau 6 complexe uitdagingen voor bedrijven oplost.

Het probleem: standaardagents vertonen vaak redeneringslatentie. Ze wachten tot de gebruiker een vraag stelt, denken vervolgens na over welke tool ze moeten gebruiken en vragen dan wellicht ook om gebruikersinformatie die al kon zijn opgehaald. Pas daarna wordt de actie aangeroepen. Dit zorgt voor een trage en onsamenhangende ervaring. Agent Script: determinisme voor de redenering.

We gebruiken de opdracht 'run' om data toe te voegen voordat het LLM zelfs maar geactiveerd wordt.

Een voorbeeld is de nood-triage-agent. Stel je voor dat een agent een melding over stroomuitval verwerkt. In plaats van de gebruiker naar diens adres te vragen en te wachten, voert het script op het moment dat de sessie start automatisch de opdracht get_current_location_by_IP en check_grid_status uit.

Het resultaat is dat de agent niet begint met "Hoe kan ik je helpen?", maar met "Ik zie dat je belt vanuit de noordelijke sector, waar een bevestigde brand in een transformator woedt. Ik heb je huishouden al toegevoegd aan de prioriteitsrestauratielijst. Is er een back-upgenerator actief?"

De logica:

Lange taakaanwijzingen (waarmee de agent alle regels tegelijk krijgt) leiden tot een verhoogde kans op hallucinaties in het redeneringsproces. De agent vergeet regel A omdat hij naar regel Z kijkt.

De Agent Script-oplossing: just-in-time instruction injection met voorwaardelijke grounding via een combinatie van RAG en voorwaardelijke logica. Hierdoor ziet de agent alleen de regels die relevant zijn voor het exacte moment van het gesprek.

Voorbeeld: regels geven voor niet-geldende aanbiedingen. Waarom zou je de agent de regels voor het aanvragen van kredietverhogingen geven als de kredietstatus van de klant dit niet eens toestaat?

De logica:

Voorwaardelijke grounding voorkomt fouten door de niet-relevante informatie geheel te verwijderen als deze niet nodig is.

Het probleem: in een complex agentgesprek (zoals een hypotheekaanvraag, sollicitatiegesprek of een technische probleemoplossingssessie) houdt de agent een lijst bij met vragen die moeten worden beantwoord, zodat alle benodigde informatie van de gebruiker wordt vastgelegd. Vaak maken gebruikers echter een gedachtesprong. Een standaardagent kan deze gedachtesprong volgen en vergeten terug te komen op deze onmisbare vragen, waardoor de aanvraag of het gesprek onvolledig is.

De kern van dit systeem is de toestandsafhankelijke navigatie, die het gesprek behandelt als een vaststaande checklist die volledig moet worden afgevinkt voordat er een overgang kan plaatsvinden.

Via toestandsafhankelijke navigatie schakelt de agent tussen onderwerpen op basis van de status van de huidige variabele of houdt deze vast aan een bepaald onderwerp totdat aan specifieke voorwaarden is voldaan. Dit voorkomt dat de agent niet-toegestane paden volgt, zelfs als een gesprek door de gedachtesprongen van een gebruiker dreigt te ontsporen. Als een gebruiker tijdens een belangrijk gesprek over een hypotheekaanvraag vraagt naar de openingstijden van filialen, volgt de agent niet gewoon het verloop van het gesprek. In plaats daarvan detecteert het script de afwijking en kan het een geforceerde overgang activeren naar een onderwerp dat de naleving waarborgt. Door de agent te vergrendelen in een specifieke 'logische ruimte' wordt het mathematisch onmogelijk dat de agent niet-goedgekeurde onderwerpen bespreekt of een sessie verlaat voordat elke verplichte variabele is vastgelegd.

Voorbeeld: de onderhoudsinspecteur. Een agent leidt een technicus door de tien stappen van een veiligheidscontrole van een vliegtuigmotor. De technicus zegt: "Wacht even, ik zag ook een kras op de romp."

Het gedrag:

1. De agent bevestigt de kras (natuurlijke taal).
2. Hij wijst de kras toe aan een variabele (statusbeheer).
3. Hij weigert de sessie te sluiten of van onderwerp te veranderen totdat hij bevestigt: "Ik heb de kras van de romp opgemerkt, maar we kunnen pas naar de buitenkant gaan als je het aanhaalmoment van de inlaatklep hebt bevestigd. Heb je deze waarde uitgelezen?"

De logica:

Een begeleid gesprek moet echter meer zijn dan alleen een lijst met opeenvolgende vragen. Anders is de agent niet meer dan een 'pratend formulier'. De primaire waarde hangt samen met een slimme gesprekssturing, waarbij de introductievragen worden gebruikt om de gebruiker naar het juiste formulier of de juiste workflow te leiden.

De overgang van een eenvoudig script naar een robuust Agent Script wordt logisch als de complexiteit toeneemt. In plaats van alleen maar vragen te stellen, wordt de agent proactief. De agent kan bijvoorbeeld stappen voor probleemoplossing ophalen uit documentatie, intern beleid raadplegen of API-aanroepen uitvoeren naar externe systemen om problemen in realtime op te lossen.

Met de introductie van Agent Script van niveau 6 in het kader van determinisme beschik je nu over alle controlemechanismen, van de vrije creativiteit van een onderwerp van niveau 1 tot de rigide, codegestuurde logica van een Agent Script van niveau 6.

Maar als je een hamer hebt, wil dat nog niet zeggen dat elk probleem een spijker is.

De meest voorkomende fout is te denken dat 'hoger ook beter is' en dat agents nu voor elke situatie volledig moeten worden aangestuurd met scripts. Dit is niet waar. De echte kunst van de architectuur en het ontwerp van agents ligt in het correct schalen van het determinisme. Dat doe je door precies genoeg controle toe te passen om de veiligheid te garanderen, zonder dat dit ten koste gaat van de gespreksflexibiliteit die AI zo waardevol maakt. Bestook je agents niet met zoveel script dat ze niet meer dan veredelde chatbots worden.

In dit hoofdstuk lees je wanneer je moet vertrouwen op de begeleide autonomie van niveau 1–5 en wanneer je de gescripte nauwkeurigheid van niveau 6 moet opleggen. Dit zijn geen strikte regels, maar meer een contextueel kader voor de verschillende opties en niveaus van determinisme.

Om de beslissing te vereenvoudigen, kunnen we de zes niveaus opdelen in twee afzonderlijke strategische zones:

• De filosofie: 'heb vertrouwen, maar hou de vinger aan de pols'. Je geeft de agent het doel, de data en de tools (die deterministisch kunnen zijn, zie niveau 5), maar je laat de redeneringsengine het beste pad kiezen om het doel te bereiken.
• Het mechanisme: probabilistische redenering. De agent analyseert de intentie van de gebruiker en selecteert dynamisch de beste tool voor de taak.
• Geschikt voor: introductie, algemene vragen en antwoorden, taken met een laag risico, breed servicebereik.

Vertrouw in de volgende gevallen op het standaard probabilistische gedrag van niveau 1 tot en met 5:

1. Het juiste pad is niet altijd hetzelfde

In veel gespreksscenario's is een rigide, hardgecodeerd pad een nadeel omdat het gesprekspad variabel is. Voor dynamische interacties, zoals persoonlijk winkelen of vakantieplanning, is er geen volgorde die altijd werkt. Zo kan een gebruiker prioriteit geven aan de prijs, locatie of voorzieningen, in elke gewenste volgorde. In deze gevallen zorgt het forceren van een toestandsafhankelijk script voor een frustrerende, robotachtige ervaring. Het is dus effectiever om te vertrouwen op instructies om de persona en doelen van de agent te definiëren, terwijl de gebruiker de richting kan aangeven. Deze aanpak verhoogt ook de time-to-market aanzienlijk, omdat het ontwikkelen van complexe niveau 6-scripts met geneste variabelen en vertakkingen vaak onnodig is voor bijvoorbeeld interne HR FAQ-agents. Door de agent te grounden op data en RAG heb je geen uitgebreid handmatig script nodig en kun je de retrieval engine het gesprek dynamisch laten voeren op basis van je bestaande knowledge base.

2. Opschalen met modulair determinisme: voorkom onderhoudsproblemen

Als je agent eenmaal op een enorme schaal functioneert (bijvoorbeeld als deze 500 verschillende IT-supportvragen kan verwerken met hun eigen processen) is de grootste uitdaging niet of je één enkel deterministisch agentisch script kunt ontwikkelen, maar of je dat wel zou moeten doen. Als je probeert om elke mogelijke combinatie van 500 taken in één gigantisch Agent Script vast te leggen, wordt het een nachtmerrie om dit te onderhouden. Elke keer dat een beleid wordt aangepast of een nieuwe stap voor probleemoplossing wordt toegevoegd, loop je het risico dat je een enorm onderling verbonden web van logica onbruikbaar maakt.

De oplossing is om over te stappen van een monolithisch script naar deterministische acties van niveau 5. In plaats van het hele gesprek te scripten, ontwikkel je robuuste, geïsoleerde stromen voor de belangrijkste en meest waardevolle acties, zoals het opnieuw instellen van wachtwoorden of het ontgrendelen van accounts. Vervolgens laat je de redeneringsengine fungeren als een verkeersleider, identificeer je de intentie van de gebruiker aan de hand van hun unieke formulering en stuur je hen door naar de juiste deterministische actie. Deze aanpak geeft je het beste van twee werelden: de betrouwbaarheid van een script voor kritieke taken én een flexibele, schaalbare architectuur die niet onwerkbaar wordt als je takenbibliotheek erg groot wordt.

• De filosofie: 'wat je ook doet en redeneert, doe in elk geval precies dit'. Jij bepaalt het pad. De agent is de interface die jouw logica uitvoert. Dit voegt de creativiteit van de agent toe aan lagen van must-do logica.
• Het mechanisme: deterministisch redeneren. Het 'brein' volgt een vooraf gecompileerd schema. Het LLM wordt alleen gebruikt voor redenering, het begrijpen van natuurlijke taal en het genereren van antwoorden waar het script dit toelaat.
• Geschikt voor: naleving, financiële transacties, diagnostische vertakkingen, belangrijke workflows en sterk gereguleerde sectoren.

Vergeet niet dat binnen de deterministische sporen van niveau 6 alle opties van niveau 1-5 nog steeds beschikbaar zijn!

Gebruik Agent Script als 'meestal goed' niet goed genoeg is.

1. De verplichte poorten (beveiliging en verificatie)

Als een gebruiker vraagt om geld over te maken, kun je er niet op vertrouwen dat het LLM waarschijnlijk wel om verificatie vraagt. Je hebt een mathematische garantie nodig dat de verificatiestroom voorafgaand aan de transactiestroom wordt uitgevoerd.

• De oplossing van Agent Script: gebruik run @actions.verify_identity in een blok before_reasoning of helemaal bovenaan je script om naleving af te dwingen voordat het LLM ook maar één token genereert.

2. Naleving van wet- en regelgeving

In sectoren zoals de gezondheidszorg of finance moeten agents een disclaimer vaak woordelijk voorlezen of in een wettelijk verplichte volgorde vragen stellen.

• De oplossing van Agent Script: programmeer deze meldingen.

3. Complexe afhankelijkheden met meerdere stappen en verplichte actiereeksen

Als stap B de output van stap A vereist en stap C afhankelijk is van een berekening uit stap B, is het riskant om op een LLM te vertrouwen om deze variabelen door te geven via een taakaanwijzingscontext. Wanneer de uitvoering van een bepaalde actie strikt verplicht is na een andere actie, moet de sequentie vast geprogrammeerd zijn.

• De oplossingen van Agent Script: gebruik set @variables.x = @outputs.y om data expliciet te koppelen tussen stappen, wat een perfecte betrouwbaarheid garandeert. Gebruik run- en @utils.transition-statements om de sequentie te coderen.

4. Voorkomen dat wordt afgeweken van het onderwerp

Bij het oplossen van belangrijke problemen (bijvoorbeeld 'mijn pacemaker piept') mag de agent niet worden afgeleid als de gebruiker plotseling vraagt of het buiten goed weer is.

• De oplossing van Agent Script: Gebruik @utils.transition om te voorkomen dat de gebruiker afwijkt van het onderwerp 'noodprotocol' totdat het probleem is opgelost. Zo wordt het onmogelijk dat deze afdwaalt.

De meest ontwikkelde agentarchitecturen kiezen niet voor het een of het ander. Ze gebruiken niveau 6 als het skelet en niveau 1-5 als de spieren. Zo ontstaat een patroon van een deterministische sandwich. Je kunt Agent Script gebruiken om het kritieke begin en einde van een gesprek af te handelen, terwijl je het middengedeelte openlaat voor flexibele redenering.

• Stap 1 (niveau 6): Agent Script dwingt triage en verificatie af.
  • Resultaat: de gebruiker is met zekerheid geïdentificeerd en de intentie is geclassificeerd.
• Stap 2 (niveaus 1-5): Agent Script-overdrachten naar een standaardonderwerp.
  • Resultaat: de agent gebruikt standaard RAG en acties, instructies en misschien zelfs variabelen om het probleem van de gebruiker flexibel op te lossen.
• Stap 3 (niveau 6): de agent detecteert dat het probleem is opgelost en gaat terug naar Agent Script voor de afsluitende acties.
  • Resultaat: Agent Script dwingt het verzamelen van CSAT-scores en een conforme afsluiting af.

Laatste aanbeveling: begin met niveau 1–5 om snel aan de slag te gaan en informatie te verzamelen, en monitor je logboeken. Als je ziet dat de agent moeite heeft met de consistentie, een sequentie niet volgt of parameters hallucineert, kun je die workflow selectief versterken met niveau 6.

Agent Script is het laatste stukje van de puzzel die determinisme naar agents brengt. Het erkent dat AI probabilistisch is, maar dat zakendoen deterministisch is. Door Agent Script te gebruiken (via het canvas dat het bouwen van agents in natuurlijke taal ondersteunt of in directe code), beperk je de intelligentie van je agent niet. Je stuurt hem alleen gerichter aan. Je creëert een systeem waarin het voeren van een gesprek samenvalt met de procesuitvoering, zodat je meest kritieke workflows altijd precies worden uitgevoerd zoals ze zijn ontworpen.

Niveau 6 laat je je ook realiseren dat autonoom niet hetzelfde is als ongecontroleerd.

Al jaren discussieert de sector over regels versus AI als het gaat om besluitvorming en procesoptimalisatie. Wie voor strikte regels is, wijst op het belang van voorspelbaarheid. De pleitbezorgers van AI roemen de flexibiliteit. Agent Script maakt een einde aan deze discussie door aan te tonen dat de beste architectuur niet uitgaat van één visie, maar beide opties combineert.

Door Agent Script te implementeren, bouw je hybride agents: systemen met zowel de rigide ruggengraat van code als de flexibele geest van een LLM. In de toekomst van zakelijke AI gaat het niet om grotere modellen, maar om betere controle. Met Agent Script krijg jij die controle eindelijk helemaal zelf.