Agenten redeneren over doelen, leiden parameters af uit context en selecteren acties dynamisch. Daarom moet elke integratie die een agent aanraakt, ambiguïteit afhandelen, veilige herhaling ondersteunen en mislukken op manieren waarop de agent autonoom kan herstellen.

Agentische systemen ontkrachten verschillende aannames die traditioneel integratieontwerp als vanzelfsprekend beschouwt. Invoer zal niet altijd goed gevormd zijn. Eén gebruikersactie kan leiden tot een keten van agenten over de grenzen van de organisatie heen, waarbij voor elke actie gedelegeerde bevoegdheid nodig is.

Dit document brengt de architectonische verschuivingen in kaart die uit die realiteit voortvloeien: de nieuwe ontwerpprincipes, de agentische patronen en de manier waarop het Salesforce-platform deze levert.

Elk patroon in dit document volgt dezelfde structuur:

Naam: De patroonidentifier die het type integratie aangeeft dat in het patroon is opgenomen.

Context: Het algemene integratiescenario waarop het patroon betrekking heeft. Context biedt informatie over wat gebruikers proberen te bereiken en hoe de toepassing zich gedraagt naar hun behoeften.

Probleem: De uitdaging (uitgedrukt als een vraag) die het patroon moet oplossen. Lees bij het beoordelen van de patronen deze sectie om snel te begrijpen of het patroon van toepassing is op uw integratiescenario.

Krachten: De beperkingen en omstandigheden die het probleem moeilijk op te lossen kunnen maken.

Toepassing Salesforce-patroon: De aanbevolen manier om het patroon toe te passen op het scenario.

Schets: Een UML-sequentiediagram (Unified Modeling Language) dat toont hoe de patroontoepassing het scenario aanpakt.

Resultaten: Hoe het patroon de aan het scenario gekoppelde krachten oplost. Deze sectie bevat ook nieuwe uitdagingen die kunnen ontstaan als gevolg van het toepassen van het patroon.

Overwegingen bij ontwerpen: Platformonafhankelijke begeleiding voor het correct toepassen van de oplossing, gevolgd door Salesforce-specifieke implementatienotities. Deze overwegingen bestrijken principes voor actieontwerp en platformspecifieke configuratievereisten.

Foutafhandeling en herstel: Richtlijn voor het beheren van storingen tijdens het aanbrengen van patronen. Deze parameter bestrijkt vier gebieden:

• Hoe acties mislukking aan de agent communiceren via gestructureerde, navolgbare foutresponsen die voldoende context bieden voor beslissingen verderop in de stroom
• Hoe de agent bepaalt of de uitvoering opnieuw moet worden geprobeerd, zichzelf moet corrigeren of moet worden stopgezet
• Hoe compensatieacties gedeeltelijke uitkomsten en niet-overeenkomende cross-platformstatus aanpakken
• Idempotentievereisten voor ingetrokken schrijfbewerkingen

Beveiligingsoverwegingen: Beveiligingsvereisten voor het veilig toepassen van het patroon. Deze overwegingen betreffen onder meer inloggegevensbeheer, minimale bereikbepaling van integratiegebruikers en verbonden apps, controlelogboekregistratie van door agenten aangeroepen acties en invoervalidatievereisten voor parameters die afkomstig zijn van door de gebruiker aangeleverde of via LLM afgeleide inhoud.

Voorbeeld: Een end-to-end scenario dat beschrijft hoe het ontwerppatroon wordt gebruikt in een Salesforce-scenario uit de praktijk. In het voorbeeld worden de doelen uitgelegd en wordt uitgelegd hoe u het patroon toepast om die doelen te bereiken.

De volgende tabel vermeldt de behandelde implementatiepatronen.

Lijst van patronen

De patronen in dit document zijn ingedeeld in drie categorieën. Deze categorisering helpt architecten snel te identificeren welke patronen relevant zijn voor de integratie-uitdaging die ze oplossen, of ze nu ontwerpen wat een agent belt, wat een agent activeert of hoe een agent Knowledge onder de knie krijgt voordat deze optreedt. In plaats van elk patroon te lezen, kunt u rechtstreeks naar de categorie navigeren die overeenkomt met uw ontwerpprobleem.

Actieaanroep:

Deze patronen bestrijken de manier waarop een agent externe systemen aanroept om gegevens op te halen of bewerkingen uit te voeren als onderdeel van de redeneercyclus. Dit zijn uitgaande patronen waarbij de agent de initiator is. Ze hebben betrekking op volgorde (wanneer stappen van elkaar afhankelijk zijn), parallellisme (wanneer ze dat niet doen), idempotentie en gedeeltelijke foutafhandeling. Gebruik deze patronen bij het ontwerpen van de tools die een agent aanroept om werk gedaan te krijgen.

Agentaanroeping:

Deze patronen gaan over de manier waarop externe systemen of events een agent in actie brengen. Dit zijn inkomende patronen waarbij externe systemen deze agenten activeren. De trigger kan een op de mens gerichte toepassing zijn die een programmatisch gesprek voert en wacht op een reactie, of een autonome gegevensvoorwaarde die de agent activeert. Gebruik deze patronen wanneer u ontwerpt hoe en wanneer een agent wordt geactiveerd.

Gronden met Enterprise Data:

De patronen in deze categorie bestrijken de manier waarop agenten worden geaard met nauwkeurige, actuele, organisatiespecifieke Knowledge voordat deze redeneert of handelt.

Het kiezen van de juiste strategie is niet triviaal. Elk patroon is gericht op een specifiek probleem: systeemmogelijkheden, gegevensvolume, foutafhandeling en transactionaliteit.

De selectiematrixtabellen vermelden de patronen en hun belangrijkste aspecten om u te helpen bepalen welk patroon het beste aansluit op uw integratievereisten. De patronen worden gecategoriseerd met behulp van deze dimensies.

Deze tabel vermeldt de patronen en hun belangrijkste aspecten om u te helpen bepalen welk patroon het beste aansluit op uw vereisten wanneer uw integratie plaatsvindt van Salesforce naar een ander systeem.

Elke sectie van patronen beschrijft hoe u ze samenstelt. Elk patroon is een herhaalbare oplossing voor een specifiek integratieprobleem in agentische architecturen. Hierin wordt beschreven wanneer het patroon moet worden gebruikt, welke krachten de beslissing bepalen en hoe het Salesforce-platform dit doet.

Context

Veel bedrijfswerkstromen zijn inherent sequentieel – elke stap vereist een geverifieerd resultaat van de vorige voordat deze kan worden uitgevoerd. Zo kan een restitutie pas worden geïnitieerd nadat de aanspraak is bevestigd, kan er pas een factuuraccount worden gemaakt nadat de orderrecord bestaat en kan er pas een nalevingscontrole worden vastgelegd nadat de controle is geslaagd.

In traditionele automatisering worden deze afhankelijkheden gecodeerd als hard-coded stroomlogica. In een agentisch systeem evalueert de agent het resultaat van elke actie en bepaalt of aan de randvoorwaarden voor de volgende stap is voldaan.

Dit patroon beschrijft het fundamentele uitgaande integratiemodel. Hier is één agent actief binnen één domein en roept een reeks aan, waarbij de uitvoer van elke actie de aanroep van de volgende actie in de keten doorgeeft. De doeltreffende agent handhaaft de transactionele context in de hele keten en verzamelt identifiers, statuscodes en gegevens die door elke stap worden geretourneerd. Het gebruikt deze context om daaropvolgende beslissingen te sturen.

Dit patroon is de agentische tegenhanger van Remote Process Invocation – Request and Reply (Aanroep en antwoord op afstand) uit de Integration Patterns Guide (Integratiepatronen), die één synchrone aanroep beschrijft. Het agentische patroon breidt het patroon uit naar een door agenten aangestuurde keten van afhankelijke gesprekken binnen één redeneercyclus.

Probleem

Wanneer een agent een werkstroom van meerdere stappen uitvoert die het hostsysteem en een of meer externe systemen bestrijkt, moeten vier uitdagingen worden aangepakt:

• Rangschikking - Acties moeten in de juiste volgorde worden aangeroepen, waarbij elke stap moet worden uitgevoerd nadat de vorige is voltooid.
• Gegevensvoortplanting - Reactiegegevens van elke stap moeten als invoer worden doorgegeven aan de volgende.
• Failure Isolation - Storingen op elk punt in de keten mogen geen gedeeltelijke of inconsistente status binnen systemen veroorzaken.
• Voltooiingsverificatie - De agent moet bevestigen dat alle stappen met succes zijn voltooid voordat een resultaat wordt gerapporteerd.

Krachten

Beantwoord bij het toepassen van dit patroon de volgende vragen:

• Is elke actie in de keten afhankelijk van gegevens die worden geretourneerd door de vorige actie, of zijn de afhankelijkheden alleen afhankelijk van de status van slagen of mislukken?

  Gegevensafhankelijkheden vereisen dat de agent ID’s en kenmerken bij zich draagt in stappen.

• Kunnen alle externe eindpunten reageren binnen de time-out van de redeneringscyclus van de agent?

  Een traag extern systeem in een willekeurige stap in de keten blokkeert de gehele reeks.

• Vereist de keten volledig end-to-end succes of is gedeeltelijke voltooiing acceptabel?

• Als volledig end-to-end succes vereist is, definieert u een compensatiestrategie voor stappen die moeten worden teruggedraaid wanneer er verderop in de stroom een storing optreedt.

• Kan een van de schrijfbewerkingen in de keten veilig opnieuw worden geprobeerd?

  Alle schrijfacties moeten idempotent zijn; de redeneringslus van de agent kan dezelfde actie meer dan eens aanroepen vanwege pogingen van het Large Language Model (LLM) of ambigue bevestigingen.

• Wordt de keten aangeroepen door een interactie van de gebruiker (gesprek, lage gelijktijdigheid) of door een geautomatiseerde trigger (potentieel hoge gelijktijdigheid)?

  Dit bepaalt of synchroon blokkeren acceptabel is of dat er een asynchroon patroon vereist is.

Toepassing Salesforce-patroon

Schets

Sequentiediagram voor aanroepen van sequentiële acties

Resultaten

De agent voert een werkstroom over meerdere systemen uit als een samenhangende, bewaakte volgorde en niet als een “fire-and-forget”-script. Het resultaat van elke stap wordt geëvalueerd voordat de volgende stap wordt aangeroepen, zodat de agent fouten zo vroeg mogelijk detecteert in plaats van gedeeltelijke voltooiing achteraf te ontdekken.

Het hostsysteem (Salesforce CRM) wordt pas bijgewerkt nadat de externe bewerking de status (succes of mislukking) heeft bevestigd. Identifiers en status die worden geretourneerd door externe systemen, zoals factuuraccountnummers, transactie-ID’s en bevestigingscodes, worden door de keten gepropageerd en bewaard, waardoor een volledige, traceerbare record van de werkstroomuitkomst wordt gemaakt.

De agent is verantwoordelijk voor het redeneren over resultaten en het nemen van beslissingen in volgorde. Elke actie is alleen verantwoordelijk voor de eigen werking en voor het retourneren van een gestructureerd resultaat. Geen van beide lagen codeert de logica van de ander.

Overwegingen bij ontwerpen

Platformonafhankelijke begeleiding

• Zorg ervoor dat elke actie in de keten een semantische beschrijving bevat die is geschreven in op intents gebaseerde taal en niet als een handtekening voor een technische methode. De agent selecteert acties op basis van deze beschrijvingen. Een beschrijving met de tekst “roept de facturerings-API aan” is minder nuttig dan een beschrijving met de tekst “maakt een factureringsaccount in het factureringssysteem en retourneert de nieuwe account-ID”.
• Maak alle schrijfbewerkingen in de keten idempotent. De redeneringslus van de agent kan een actie opnieuw proberen als deze een ambigue respons ontvangt. De actie moet hetzelfde resultaat opleveren bij herhaald aanroepen.
• Valideer alle via LLM afgeleide invoerparameters defensief op de actiegrens. Neem nooit aan dat parameters die door de agent worden doorgegeven, goed gevormd zijn, binnen het bereik liggen of van het verwachte type zijn.
• Ontwerp elke actie voor één verantwoordelijkheid. Een actie die een factureringsaccount maakt en een bevestigings-e-mailbericht verzendt in hetzelfde gesprek, is moeilijker opnieuw te proberen, moeilijker te testen en moeilijker voor de agent om te redeneren dan twee afzonderlijke acties.

Implementatienotities voor Salesforce

• Annoteer voor Apex acties met @InvocableMethod(label=’…’ description=’…’). De “beschrijving” wordt gelezen door de agent om te bepalen wanneer de actie moet worden aangeroepen. Declareer alle invoer- en uitvoervariabelen met @InvocableVariable met behulp van beschrijvende “label”- en “description”-velden. Retourneer gestructureerde resultaatobjecten met expliciete succes-/mislukkingsindicatoren en voor mensen leesbare foutberichten.
• Gebruik voor Stroomacties uitsluitend Automatisch gestarte stromen; schermstromen worden niet ondersteund in autonome agentcontexten. Houd elke stroom atomair; één actie, één verantwoordelijkheid. Configureer foutpaden voor elk extern aanroepelement om integratiefouten op te sporen en navolgbare foutberichten te retourneren aan de agent, in plaats van niet-vastgelegde uitzonderingen de sessie te laten beëindigen.
• Importeer voor Externe services de OpenAPI-specificatie van het doelsysteem en registreer de gegenereerde acties in het Agentforce Onderwerp. Wikkel de gegenereerde stubs in Benoemde inloggegevens om hardcoding-eindpunten of inloggegevens in de actiedefinitie te voorkomen.
• Stel voor alle externe aanroepen expliciete aanroeptime-outs in. Een aanroep die zonder time-out blijft hangen, blokkeert de redeneercyclus van de agent totdat de sessielimiet is bereikt. Retourneer een gracieuze fout met een beschrijvend foutbericht wanneer de time-out wordt overschreden. Alle externe aanroepen hebben een configureerbare time-out van maximaal 120 seconden. Ze zijn ook onderworpen aan Apex beheerlimieten voor synchrone transacties. Zorg er dus voor dat u het risico verkleint dat u meer dan 50 transacties instantieert die elk meer dan vijf seconden worden uitgevoerd.

Foutafhandeling en herstel

• De agent wijst elke stap af op het expliciete succes van de voorganger van de stap. Acties moeten een gestructureerd resultaat retourneren dat een duidelijke succes- of foutindicator bevat. De agent kan mislukking niet alleen afleiden uit een ontbrekende of null-respons.
• Wanneer een actie mislukt, gebruikt de agent het foutbericht dat door de actie wordt geretourneerd om de volgende zet te bepalen: vraag de gebruiker om gecorrigeerde invoer, probeer het opnieuw met aangepaste parameters of stop de keten en leg de fout vast voor menselijke beoordeling. Daarom moeten foutberichten specifiek en bruikbaar zijn: “Ongeldig datumbereik: endDate kan niet voorafgaan aan startDate” is bruikbaar; 400 statuscode alleen niet.
• Voor ketens waarin gedeeltelijke voltooiing een inconsistente status creëert (bijvoorbeeld, de factuuraccount is gemaakt, maar de CRM-record is niet bijgewerkt), roept de agent een compensatieactie aan om de gedeeltelijke status terug te draaien of te signaleren voordat de fout zichtbaar wordt. Ontwerp compensatietrajecten als benoemde acties naast het voorwaartse traject.
• Als een schrijfactie potentieel is geslaagd, maar een ambigue respons heeft geretourneerd (netwerktime-out, geen bevestiging), moet de nieuwe poging dezelfde idempotentiesleutel of externe verwijzings-ID gebruiken als de oorspronkelijke aanroep. Geef nooit een niet-gecontroleerde nieuwe poging uit op een niet-idempotent schrijven.

Beveiligingsoverwegingen

• Wikkel alle externe aanroepen in benoemde gegevens. Nooit hardcode eindpunten of inloggegevens in Apex code of Flow configuraties. Deze moeten worden beheerd via de beveiligde inloggegevensopslag van het platform en worden geroteerd zonder codewijzigingen.
• Pas het principe van de minste rechten toe op de integratiegebruiker of verbonden app die door elke actie wordt gebruikt. Een actie die alleen ordergegevens leest, mag geen schrijfmachtigingen hebben voor het factureringssysteem. Bereik inloggegevens tot het minimum aantal bewerkingen dat de actie vereist.
• Leg de aanroep van elke actie in de keten vast met de sessie-ID, invoerparameters (geanonimiseerd van gevoelige waarden) en uitkomst. Als het resultaat wordt betwist, is dit controletraject het primaire mechanisme om te reconstrueren waarom de agent een bepaalde volgorde van acties heeft uitgevoerd.
• Reinig alle invoerparameters die afkomstig zijn van door de gebruiker opgegeven tekst voordat u ze doorgeeft aan externe systemen. Gebruikersinvoer die via de agent wordt doorgegeven aan een externe API-aanroep, is een potentiële injectievector. Valideer type, indeling en bereik aan de actiegrens voordat de aanroep wordt gedaan.

Voorbeeld

Een klantenserviceagent die een restitutieverzoek afhandelt, voert een sequentiële keten van vier stappen uit:

1. GetOrderDetails (Apex Action) haalt de orderrecord op uit het Orderbeheersysteem met behulp van de door de gebruiker opgegeven order-ID. Deze retourneert orderstatus, regelitems, aankoopdatum en betalingswijze. De agent evalueert of de order een restitueerbare staat heeft voordat hij doorgaat.
2. ValidateRefundEligibility (Automatisch gestarte stroom) past de bedrijfsregels toe voor aanspraak op restitutie, inclusief retourperiode, beperkingen van productcategorieën en eerdere restitutiehistorie. Het retourneert een “in aanmerking komende” booleaanse reden en, indien niet in aanmerking komend, een duidelijke taalreden die de agent aan de gebruiker kan tonen.
3. InitiateRefund (Apex Action) roept de externe betalingsgateway-API aan met de order-ID en het restitutiebedrag. Retourneert een “refundTransactionId” bij succes. Deze actie is idempotent. Bij een tweede aanroep met dezelfde order-ID retourneert deze de bestaande transactie-ID in plaats van een duplicaatrestitutie te maken.
4. UpdateCaseStatus (Automatisch gestarte stroom) werkt de CRM-caserecord bij met de ID van de restitutietransactie, stelt de casestatus in op “Opgelost restitutieprobleem” en maakt een vervolgtaak voor de accounteigenaar. Deze stap wordt alleen uitgevoerd nadat “InitiateRefund” een bevestigde transactie-ID heeft geretourneerd.

Als InitiateRefund een time-out ondervindt of een fout retourneert, stopt de agent de keten, roept deze geen UpdateCaseStatus aan en wordt er een bruikbaar bericht weergegeven voor de gebruiker. De case blijft open en onopgelost, waardoor de nauwkeurige status in het CRM behouden blijft.

Context

Sequentiële actieketens zijn efficiënt wanneer uitvoeringsstappen van elkaar afhankelijk zijn. De ene stap gaat over op de volgende. Maar veel werkstromen bevatten een set stappen die geen onderlinge afhankelijkheden hebben. Zo kunnen stappen zoals het ophalen van productvoorraad, het ophalen van klantrechten en het controleren van een verzendschatting allemaal gelijktijdig plaatsvinden, aangezien voor geen enkele stap de uitvoer van een andere nodig is. Door deze stappen sequentieel uit te voeren verspilt u tijd evenredig aan het aantal stappen.

In een parallel aanroeppatroon geeft de agent aan dat een set acties onafhankelijk is en roept deze gelijktijdig aan in plaats van in volgorde. De totale werkstroomtijd is gebonden aan de traagste afzonderlijke actie in plaats van de som van alle actietijden. Zodra alle resultaten zijn geretourneerd, aggregeert de agent ze tot één samenhangende respons of gebruikt deze samen als invoer voor de volgende fase van het redeneren.

De belangrijkste architectonische uitdaging is niet de parallelle aanroep zelf. Het is het beheren van fan-out binnen beperkingen voor platformgelijktijdigheid en ervoor zorgen dat de aggregatiestap gedeeltelijke mislukkingen op een nette manier afhandelt, zonder de resultaten te negeren die wel zijn geslaagd.

Probleem

Hoe orkestreert een agent efficiënt de gelijktijdige uitvoering van meerdere, onafhankelijke mogelijkheden en aggregeert de afzonderlijke resultaten in één samenhangende reactie voor de gebruiker of daaropvolgende stappen?

Krachten

Beantwoord bij het toepassen van dit patroon de volgende vragen:

• Wat zijn de overwegingen bij acties met betrekking tot threadveiligheid en delen van muteerbare status?
• Hoe kan de oplossing Salesforce beheerlimieten voor parallelle Apex aanroepen beheren en vermijden binnen één transactie?
• Is het nodig om asynchrone patronen (zoals Apex of Platform-events in wachtrij) te gebruiken om beheerlimieten te vermijden?
• Is synchrone aggregatie van de resultaten vereist voordat de agent kan doorgaan?

Toepassing Salesforce-patroon

Schets

Sequentiediagram voor aanroepen van parallelle actie

Resultaten

Wanneer onafhankelijke acties parallel worden uitgevoerd, is de end-to-end werkstroomtijd gebonden aan de traagste afzonderlijke actie in plaats van de som van alle acties. Voor een werkstroom met drie onafhankelijke aanroepen van gemiddeld 300 ms elk, wordt de parallelle uitvoering voltooid in ~300 ms; de sequentiële uitvoering duurt ~900 ms. Op schaal wordt dit verschil groter voor elke agentsessie die tegelijkertijd wordt uitgevoerd.

Overwegingen bij ontwerpen

Platformonafhankelijke begeleiding

• Bevestig de onafhankelijkheid voordat u parallelliseert. Acties kunnen alleen veilig parallel worden uitgevoerd als geen van beide acties de status leest die door de andere is geschreven, en als geen van beide acties mislukt, wordt de andere actie geannuleerd. Als er een afhankelijkheid bestaat, zelfs een zachte, gebruikt u in plaats daarvan sequentiële ketens.
• Ontwerp de aggregatiestap expliciet. Bepaal vooraf hoe een volledige resultatenset eruitziet, wat een gedeeltelijke resultatenset betekent voor redeneren verderop in de stroom en of de agent moet wachten op alle resultaten of moet doorgaan zodra een drempelwaarde (bijvoorbeeld vijf van de zeven gesprekken) is teruggekeerd.
• Alle parallelle schrijfbewerkingen moeten idempotent zijn. Elke bewerking wordt geïsoleerd uitgevoerd zonder een gedeelde transactiegrens, dus het opnieuw proberen van een afzonderlijke vertakking kan geen neveneffecten dupliceren.

Implementatienotities voor Salesforce

• Voor Apex met wachtrij: Dien alle taken binnen één transactie in om de kans op gelijktijdige uitvoering te maximaliseren. Houd er rekening mee dat beschikbare gelijktijdige tijdstippen worden gedeeld door de hele organisatie; ontwerp met de veronderstelling dat tijdstippen mogelijk niet altijd beschikbaar zijn en bouw een reservemogelijkheid in voor sequentiële uitvoering wanneer dit niet het geval is.
• Voor platformevents: Schrijf het resultaat van elke bewerking naar een speciale faseringsrecord (gesleuteld door een gedeelde correlatie-ID) in plaats van de doelrecord rechtstreeks bij te werken. Een laatste aggregatiestroom of Apex trigger leest alle faseringsrecords zodra de verwachte telling is bereikt en past de geconsolideerde update vervolgens atomair toe.
• Voor Middleware Fan-Out: Stel een expliciete time-out in voor de ene aanroep die langer is dan de verwachte reactietijd in het slechtste geval van de traagste back-end, maar nog steeds binnen de time-outlimiet van Salesforce-aanroepen. De middleware retourneert gedeeltelijke resultaten met een duidelijke indicatie van welke back-ends zijn mislukt, in plaats van de gehele respons te timen.

Foutafhandeling en herstel

• Beschouw gedeeltelijk succes als een eersteklas uitkomst. Als drie of vier parallelle bewerkingen slagen, gebruikt de agent de drie geslaagde resultaten en handelt de fout af door deze expliciet zichtbaar te maken voor de gebruiker, vast te leggen voor een nieuwe poging of een compenserende actie aan te roepen in plaats van alle resultaten te negeren of door te gaan alsof de fout niet is opgetreden.
• Gebruik voor wachtrij- en platformeventpatronen een correlatie-ID (gegenereerd op het moment van uitwaaieren) om alle parallelle vertakkingen terug te koppelen naar de sessie van de oorspronkelijke agent. Deze ID is vereist om resultaten opnieuw samen te stellen en fouten te traceren naar hun bron in logboeken.
• Als een parallelle vertakking mislukt en de bewerking veilig opnieuw kan worden geprobeerd, plaatst u alleen de mislukte vertakking opnieuw in de wachtrij met behulp van de oorspronkelijke correlatie-ID en idempotentiesleutel. Roep niet alle vertakkingen opnieuw aan.
• Definieer een time-outdrempel voor de aggregatiestap. Als niet alle resultaten binnen de drempelwaarde komen, gaat u door met de beschikbare resultaten en signaleert u de onvolledige set in plaats van oneindig te wachten.

Beveiligingsoverwegingen

• Elke parallelle uitvoeringscontext, of het nu een wachtrijtaak, een platformeventtrigger of een middleware-aanroep betreft, moet dezelfde toegangsbesturingselementen toepassen als een sequentiële aanroep. Parallellisme versoepelt de regels voor gegevenstoegang niet. Elke vertakking moet werken onder hetzelfde inloggegeven met de minste rechten als wanneer dit alleen zou worden aangeroepen.
• Voor middlewarefan-out slaat de middlewarelaag geen responspayloads op in het cachegeheugen of logboek van afzonderlijke back-ends buiten het aggregatievenster. De respons van elke back-end kan gevoelige gegevens bevatten die niet buiten het bereik van de directe bewerking mogen blijven.
• Zorg ervoor dat de faseringsrecords die worden gebruikt voor platformeventaggregatie, niet leesbaar zijn voor de eindgebruiker van de agent. Deze records kunnen tussentijdse, gedeeltelijk gevormde gegevens bevatten die nog niet geschikt zijn voor verbruik.

Voorbeeld

Een serviceagent beantwoordt een complexe leveringsvraag: “Kunt u deze bestelling vrijdag naar mij verzenden?” Het antwoord vereist gegevens uit alle onafhankelijke systemen tegelijk, zoals hieronder uitgelegd:

1. De agent identificeert drie onafhankelijke gegevensbehoeften: het huidige voorraadniveau, de actieve rechten van de klant en de geschatte leveringsperiode van de provider voor de locatie van de klant.
2. Drie acties worden parallel aangeroepen: GetInventoryStatus (vanuit het externe voorraadsysteem via middleware), GetCustomerEntitlements (vanuit Salesforce CRM) en GetDeliveryEstimate (vanuit de carrier-API via middleware).
3. Elke actie wordt onafhankelijk geretourneerd. De agent wacht totdat alle drie de responsen zijn ontvangen (of totdat de aggregatietime-out is bereikt).
4. Nu alle drie de resultaten beschikbaar zijn, beredeneert de agent de gecombineerde gegevens, beoordeelt hij of de voorraad voldoende is, dekt het recht van de klant expresverzending en bevestigt de vervoerder dat levering op vrijdag haalbaar is voor de postcode van de klant.
5. De agent retourneert één gefundeerd antwoord aan de gebruiker, dat afkomstig is uit drie systemen, in de tijd die de traagste van de drie gesprekken vergde om te reageren.

Context

Sommige door agenten geïnitieerde bewerkingen leveren geen resultaat op dat de agent nodig heeft om door te gaan met zijn huidige redeneercyclus. Het verzenden van een kennisgeving, het activeren van een batchproces verderop in de stroom, het publiceren van een event naar een berichtenwachtrij of het indienen van een langlopende taak zijn allemaal bewerkingen waarbij de verplichting van de agent eindigt bij verzending; het downstreamsysteem neemt eigendom en voltooit het werk zelfstandig.

In traditionele automatisering worden deze gemodelleerd als fire-and-forget-aanroepen of platformeventpublicaties. In een agentisch systeem besluit de agent tijdens het redeneren dat de bewerking niet blokkeert, verzendt deze, registreert de bevestiging van verzending en gaat door of sluit de beurt zonder te wachten op de uitkomst verderop in de stroom.

Dit patroon is de agentische tegenhanger van Remote Process Invocation – Fire and Forget uit de handleiding Integratiepatronen. Het agentische patroon breidt dit uit door de beslissing over verzending onderdeel te maken van de redenering van de agent en door ervoor te zorgen dat de verzending traceerbaar is, ook al wordt er geen reactie geretourneerd aan de agent.

Probleem

Wanneer een agent een bewerking verderop in de stroom moet initiëren die verder gaat dan de sessie of redeneercyclus van de agent, moeten drie uitdagingen worden aangepakt:

• Niet-blokkerende aanroep: De agent moet de bewerking starten en de levering bevestigen zonder de redeneercyclus open te houden in afwachting van een resultaat.
• Bevestiging van levering: De agent moet onderscheid maken tussen een geslaagde verzending (het bericht is geaccepteerd) en een geslaagd resultaat (het proces verderop in de stroom). Het kan alleen het eerste doen gelden.
• Traceerbaarheid: Omdat de agent geen resultaat ontvangt, moet de bewerking kunnen worden gevolgd via logboeken, eventrecords of platformbewaking, onafhankelijk van de agentsessie.

Krachten

Beantwoord bij het toepassen van dit patroon de volgende vragen:

• Heeft de agent het resultaat van deze bewerking nodig om de huidige beurt te voltooien? Zo ja, dan is dit niet het juiste patroon. Gebruik in plaats daarvan Sequentiële actieaanroep.

• Kan het downstreamsysteem het verzonden bericht of de verzonden event ontvangen en betrouwbaar verwerken zonder een synchrone bevestiging? Het doelsysteem moet duurzaam zijn. Het bericht mag niet verloren gaan als het tijdelijk niet beschikbaar is.

• Is de operatie idempotent of moet dubbele verzending worden bewaakt? Opnieuw proberen op netwerkniveau en opnieuw proberen met agenten te redeneren kunnen ertoe leiden dat dezelfde verzending meer dan eens wordt geprobeerd. Als de bewerking verderop in de stroom niet idempotent is, moet de actie een deduplicatiesleutel hebben.

• Moet de gebruiker of een proces verderop in de stroom weten wanneer de bewerking is voltooid? De agent kan alleen de verzending bevestigen. Als de voltooiingsstatus vereist is, ontwerpt u een afzonderlijk kennisgevings- of vervolgmechanisme. Een Platform-event, een case-update of een callback - die buiten deze redeneercyclus valt.

Toepassing Salesforce-patroon

Schets

Sequentiediagram voor aanroepen van asynchrone acties

Resultaten

De agent roept een bewerking verderop in de stroom aan zonder de redeneringscyclus voor de uitkomst ervan te blokkeren. De beurt wordt voltooid met de bevestiging dat de bewerking is geaccepteerd, niet dat deze is voltooid. Het downstream-systeem neemt het volledige eigendom van de uitvoering over. De verzonden bewerking is traceerbaar via platformeventabonnees, taak-ID’s of externe wachtrijbevestigings-ID’s die op het moment van verzending in het CRM worden vastgelegd. Als de bewerking verderop in de stroom mislukt, wordt dat probleem zichtbaar via de eigen bewaking van het verderop in de stroom gelegen systeem, niet via de agentsessie die het heeft geïnitieerd.

Overwegingen bij ontwerpen

Platformonafhankelijke begeleiding

• Schrijf actiebeschrijvingen in op intents gebaseerde taal. Zo is “Een verlengingskennisgeving indienen bij de berichtenwachtrij en een verzendingsreferentie-ID retourneren” nuttiger voor de agent dan “het kennisgevingseindpunt aanroepen”.
• Beschrijf een verzendingsactie nooit als “verzendt en bevestigt levering van”. De agent kan de acceptatie alleen bevestigen. Levering en verwerking verderop in de stroom vallen buiten de waarnemingsmogelijkheden van de agent.

Implementatienotities voor Salesforce

• Retourneer een verwijzings-ID van elke aanroepactie, bijvoorbeeld een Platform Event ReplayId, een Wachtrijtaak-ID, een Pub/Sub API PublishResult replayId of een extern erkenningstoken. Leg deze vast in een CRM-record op het moment van aanroepen. Dit is het enige controletraject dat de agentsessie zal opleveren.
• Voor Pub/Sub API roept de agent een Apex actie aan die een gRPC aanroep doet naar het Pub/Sub API ‘/Publish’ eindpunt. De actie moet de schemaregistratiestap afhandelen - events moeten in Avro-indeling worden geserialiseerd ten opzichte van het geregistreerde schema. Retourneer de PublishResult ‘replayId’ naar de agent als de verzendingsverwijzing.
• Roep voor Platform Events EventBus.publish() aan binnen de Apex actie en controleer SaveResult op fouten voordat u een succesindicator retourneert naar de agent. Ga niet uit van publicatiesucces; valideer het.
• Implementeer voor Wachtrijtaken de interface Wachtrij en roep System.enqueueJob() aan vanuit de actie. Retourneer de resulterende AsyncApexJob-ID naar de agent.
• Voor externe asynchrone eindpunten moet het doeleindpunt onmiddellijk een bevestiging retourneren (HTTP 202 geaccepteerd) met een verwijzings-ID. Als het eindpunt blokkeert totdat de verwerking is voltooid, is het synchroon en is dit patroon niet van toepassing.

Foutafhandeling en herstel

• Een aanroepactie moet onderscheid maken tussen een mislukte verzending (het bericht is niet geaccepteerd) en een mislukte verwerking (het bericht is geaccepteerd, maar de bewerking verderop in de stroom is later mislukt). De agent kan alleen de eerste afhandelen.
• Als de aanroep mislukt, moet de actie een gestructureerde fout retourneren met een duidelijke reden. De agent kan de verzending opnieuw proberen, escaleren naar een mens of een mislukte verzendingsrecord vastleggen, maar kan een verwerkingsfout verderop in de stroom niet herstellen binnen dezelfde sessie.
• Voor bewerkingen waarbij storingen verderop in de stroom uiteindelijk zichtbaar moeten worden, ontwerpt u een afzonderlijke feedbacklus, zoals een Platform-event dat door het proces verderop in de stroom wordt gepubliceerd, een geplande stroom die de taakstatus controleert, of een vervolgcase die buiten de agentsessie valt.

Beveiligingsoverwegingen

• Wikkel alle externe asynchrone aanroepen in benoemde gegevens. De aanroepactie bedt geen eindpunt-URL’s of inloggegevens in code in.
• Valideer en zuiver alle parameters die zijn doorgegeven aan de aanroepactie voordat ze worden ingebed in de eventpayload of hoofdtekst van het bericht. Door de gebruiker aangeleverde tekst die wordt doorgegeven in een asynchroon bericht, is een potentiële injectievector in de downstream-consument.
• Leg elke verzending vast met sessie-ID, verwijzings-ID en opgeschoonde payload op het moment van verzending. Omdat er geen respons naar de agent wordt geretourneerd, is dit logboek het primaire mechanisme voor het reconstrueren van wat de agent heeft geïnitieerd.
• Pas least-privilege toe op de integratiegebruiker of verbonden app. Een verzendingsactie die naar een kennisgevingswachtrij publiceert, mag geen inloggegevens bevatten die lezen of schrijven op niet-gerelateerde systemen toestaan.

Voorbeeld

Een agent voor verlengingsbeheer die een contract afhandelt dat bijna verloopt, bepaalt dat de klant in aanmerking komt voor een kennisgeving over automatische verlenging. De agent heeft geen bevestiging nodig dat de e-mail is afgeleverd voordat de beurt is voltooid.

1. CheckRenewalEligibility (Automatisch gestarte stroom) evalueert contractvoorwaarden, klantlaag en afmeldingsstatus. Retourneert een “in aanmerking komende” booleaan en het voorkeurskanaal voor kennisgevingen.
2. DispatchRenewalNotification (Apex Action) publiceert een RenewalNotification\_\_e Platform Event met daarin de contract-ID, klant-ID, kennisgevingskanaal en een gegenereerde idempotentiesleutel. Retourneert een ReplayId die bevestigt dat de event is geaccepteerd door het platform.
3. UpdateContractRecord (Automatisch gestarte stroom) schrijft het ReplayId en het verzendtijdstempel naar de contractrecord en stelt een statusvlag “Kennisgeving verzonden” in.

Context

Externe toepassingen zoals klantportals, mobiele apps, externe SaaS-platforms en partnersystemen moeten agenten programmatisch aanroepen om serviceaanvragen te verwerken, werkstromen te starten of door AI gestuurde reacties zichtbaar te maken binnen hun eigen interfaces. De agent fungeert als een intelligente back-endservice. Het externe systeem biedt context, de redenen en acties van de agent, en de beller verbruikt de respons.

De beller is zelf steeds meer een AI-agent of orchestrator in plaats van een op de mens gerichte toepassing. In deze AI-naar-AI-patronen delegeert een orkestrerende agent een redeneringsstap, CRM-opzoekactie of actie aan Agentforce als een afzonderlijke toolaanroep. We moeten een MCP-server (Model Context Protocol) zichtbaar maken om dit patroon te ondersteunen.

Probleem

Wanneer een extern systeem of een AI-agent de mogelijkheden van een Agentforce agent on demand moet benutten, hoe authenticeert deze dan, maakt deze een agentsessie, geeft deze de benodigde gespreks- en contextuele gegevens door en ontvangt deze betrouwbaar de gestructureerde reactie van de agent om zijn eigen logica verderop in de stroom te sturen?

Krachten

Beantwoord bij het toepassen van dit patroon de volgende vragen:

• Verwacht de externe beller een synchrone reactie met een lage latentie of is een asynchrone callback acceptabel?
• Hoe wordt de identiteit van de beller vastgesteld en doorgevoerd in de uitvoeringscontext van de agent voor gegevenstoegang en personalisering?
• Wat is het verwachte volume van gelijktijdige door API geactiveerde sessies en hoe heeft dat een interactie met de Salesforce API-score en gelijktijdigheidslimieten?
• Moet het externe systeem sessiecontinuïteit handhaven over meerdere beurten (gesprek met meerdere beurten) of is elk verzoek statusloos?
• Hoe moet de reactie van de agent worden gestructureerd zodat het aanroepsysteem deze programmatisch kan parseren en ernaar kan handelen?
• Is de aanroeper een op mensen gerichte toepassing die directe REST-integratie vereist, of een AI-agent of orchestrator die Agentforce als tool kan aanroepen via een standaardprotocol, zoals MCP?

Toepassing Salesforce-patroon

Schets

Sequentiediagram voor On-demand Agent-aanroeping

Resultaten

Dit patroon maakt Agentforce zichtbaar als een aanroepbare AI-service. Externe systemen krijgen toegang tot de redenering, tools en CRM-context van de agent zonder die logica te repliceren. De beller blijft verantwoordelijk voor het beheer van de levenscyclus van de sessie en het weergeven van de respons. De agent blijft verantwoordelijk voor alle redeneringen, toolselectie en responssynthese.

Wanneer de aanroeper een AI-agent of orchestrator is, neemt het Agentforce via MCP-mechanisme (kant-en-klaar beschikbaar via Salesforce Headless 360) de noodzaak voor een aangepaste REST-integratie volledig weg. De MCP-server handelt de sessielevenscyclus af namens de aanroepende agent, waardoor Agentforce als eersteklas tool kan deelnemen aan werkstromen voor meerdere agenten zonder extra sanitair.

Overwegingen bij ontwerpen

Platformonafhankelijke begeleiding

• Vermijd het synchroon maken van de externe API-aanroep en blokkeren in tijdgevoelige UI-stromen. Gebruik een polling- of webhookcallbackpatroon waarbij reactietijden van agenten niet triviaal zijn, om de gebruikerservaring los te koppelen van de verwerkingstijd van de agent.
• Selecteer het aanroepmechanisme op basis van de aard van de beller, niet de beschikbaarheid. Voor de mens bestemde toepassingen en systeemintegraties moeten rechtstreeks de Agent-API gebruiken. Tools die MCP’s ondersteunen, moeten de Agentforce MCP-server gebruiken. Mengmechanismen voor hetzelfde type aanroeper voegen onnodige complexiteit toe zonder architectonisch voordeel.

Implementatienotities voor Salesforce

• Voeg sessiecontext toe in de POST-aanvraag voor het maken van de sessie, niet in het eerste gebruikersbericht. Wanneer het externe systeem de sessie maakt, heeft het de mogelijkheid om gestructureerde contextvariabelen (account-ID, rechtengegevens, samenvatting van voorafgaande interactie) rechtstreeks door te geven als benoemde sessieparameters. Deze variabelen zijn beschikbaar voor de agent voordat deze één beurt verwerkt, waardoor deze begint te redeneren vanuit een gefundeerde status zonder opzoekaanroepen uit te geven om te bepalen wie de klant is of waar deze recht op heeft. Het doorgeven van dezelfde gegevens in de hoofdtekst van het bericht dwingt de agent in plaats daarvan om ongestructureerde tekst te parseren om feiten te extraheren die deze als getypte variabelen had kunnen ontvangen - het vergroten van de latentie, het introduceren van extractiefouten en het verbruiken van redeneerstappen die geen bedrijfswaarde toevoegen.
• Ontwerp responsen van agenten om gestructureerd en machine-parseerbaar te zijn. Gebruik uitvoervariabelenconventies en aanwijzingsinstructies die de agent begeleiden om JSON-vriendelijke of duidelijk gescheiden reacties te retourneren wanneer de aanroeper een systeem is in plaats van een mens.
• Sessielevenscyclus expliciet beheren. Beëindig sessies onmiddellijk na gebruik DELETE /einstein/ai-agent/v1/sessions/{sessionId} om gelijktijdige tijdstippen vrij te maken en te voorkomen dat er een verouderde context blijft bestaan binnen niet-gerelateerde interacties.
• Houd rekening met gelijktijdige sessielimieten van Salesforce. Implementeer voor scenario’s met hoge doorvoer een sessiepool of een wachtrijlaag in het aanroepsysteem om afwijzing van verzoeken tijdens piekbelasting te voorkomen.
• Geef bij het aanroepen van Agentforce via MCP context door als toolinvoerparameters in plaats van als sessievariabelen. De MCP-server beheert de levenscyclus van de sessie transparant, waardoor de aanroepende agent benoemde sessieparameters niet rechtstreeks op het moment van maken kan instellen. Zorg ervoor dat alle vereiste context (record-ID’s, gebruikersidentiteit, rechtengegevens) is opgenomen in de payload van de toolaanroep, zodat de agent kan gaan redeneren vanuit een gefundeerde status.
• Beschouw het transparante sessiebeheer van de MCP-server als een gemak, niet als een gelijktijdige bypass. Elke toolaanroep verbruikt nog steeds een Salesforce-agentsessietijdstip. High-frequency orchestrators die Agentforce via MCP op schaal aanroepen, moeten rekening houden met dezelfde gelijktijdige sessielimieten die gelden voor directe Agent-API-aanroepen.

Foutafhandeling en herstel

• De Agent-API retourneert standaard HTTP-foutcodes. Het aanroepsysteem moet “429 Too Many Requests” (snelheidslimiet) met exponentiële backoff en “503 Service Unavailable” met retry logica afhandelen.
• Wanneer de agent zelf een onoplosbare toolfout ondervindt, retourneert deze een gracieuze natuurlijke-taalfout in de hoofdtekst van de reactie. Het aanroepsysteem detecteert deze verklikkerreacties (bijvoorbeeld door te controleren op een “fout”-statusveld in de respons) en routeert dienovereenkomstig door het opnieuw te proberen met extra context, een reserve-ervaring te presenteren of te escaleren naar een mens.
• Bij aanroepen via MCP worden fouten zichtbaar op twee afzonderlijke lagen: MCP-transportfouten (foutieve toolaanroepen, onbeschikbaarheid van de server) en Agentforce redeneringsfouten (tooluitvoeringsfouten, onoplosbare acties). De orkestrerende agent moet beide lagen onafhankelijk afhandelen. MCP-transportfouten moeten nieuwe pogingen activeren op protocolniveau; Agentforce redeneringsfouten die worden geretourneerd in de toolrespons, moeten worden afgehandeld door de eigen reserve- of escalatielogica van de orchestrator.

Beveiligingsoverwegingen

• Gebruik de smalst mogelijke OAuth-bereiken voor de externe clientapp. Een integratie die alleen een agent hoeft aan te roepen, mag geen bereik voor gegevenstoegang hebben dat verder gaat dan wat de agent zelf nodig heeft.
• Valideer en zuiver alle invoer van het externe systeem voordat u deze injecteert als sessievariabelen. Externe invoer is een aanvalsoppervlak voor snelle injectie. Zo kan een kwaadwillende beller een veld “customerQuery” maken om instructies van agenten te overschrijven.
• Pas IP-whitelisting toe op de externe clientapp om te beperken welke externe systemen de Agent-API kunnen authenticeren en aanroepen.
• Leg alle door de API geactiveerde sessies vast met de identiteit van de beller, sessie-ID en metagegevens voor verzoeken/reacties voor audit- en beveiligingsdoeleinden.
• Wanneer Agentforce wordt aangeroepen via MCP, verifieert de MCP-server Salesforce namens de aanroepende gebruiker. Zorg ervoor dat de inloggegevens van de verbonden app voor de MCP-server zijn beperkt tot het minimum aantal vereiste machtigingen en dat de identiteit van de eindgebruiker (met behulp van MCP-tools zoals Claude) expliciet via toolinvoerparameters wordt doorgegeven aan de sessiecontext.

Voorbeeld

Een Financial Services Portal activeert een Agentforce agent om een hypotheekaanvraag af te handelen.

1. De portal authenticeert met behulp van de OAuth-stroom Client Credentials en verkrijgt een bearertoken.
2. Het roept “POST / Einstein/ai-agent/v1/sessions” aan met sessievariabelen: ”{ “accountId”: “001xx…”, “productType”: “mortgage”, “loanAmount”: 450000 }”.
3. De gebruiker dient zijn of haar vraag in: “Welke documenten heb ik nodig om mijn aanvraag in te vullen?”
4. De portal roept “POST / Einstein/ai-agent/v1/sessions/ {sessionId} / messages” aan met de tekst van de gebruiker.
5. De Agentforce agent roept een stroomactie GetDocumentChecklist aan, haalt de leningspecifieke vereisten op en retourneert een gestructureerde lijst.
6. De portal geeft de reactie van de agent inline weer en sluit de sessie bij het verlaten van de gebruiker.

Context

Niet alle agentische werkstromen zijn afkomstig van een menselijk verzoek. Bedrijfskritieke signalen zoals een plotselinge daling in meetgegevens over productgebruik, het verlaten van een winkelwagentje met een hoge waarde of een betalingsfout die een risicodrempel overschrijdt, komen vaak voor in operationele gegevens. Wanneer deze signalen intelligente reacties in meerdere stappen vereisen, leidt het wachten tot een mens het opmerkt en handelt tot latentie die leidt tot reële bedrijfskosten.

Dit patroon beschrijft hoe realtime events fungeren als autonome toegangspunten voor agenten. De agent wordt aangeroepen door een gegevensvoorwaarde in plaats van een gebruiker, redeneert over de eventcontext en voert een reactiewerkstroom uit zonder menselijke initiatie.

Probleem

Wanneer een real-time bedrijfsevent plaatsvindt in Data 360 of het Salesforce Platform, hoe kan die event dan autonoom een agentsessie instantiëren, de eventpayload leveren als basiscontext en een werkstroom voor niet-gespreksacties voltooien zonder dat een mens de interactie initieert of begeleidt?

Krachten

Beantwoord bij het toepassen van dit patroon de volgende vragen:

• Is er onmiddellijk een reactie vereist op het moment dat de event wordt geactiveerd of is verwerking in vrijwel realtime (seconden tot minuten) acceptabel?
• Bevat de eventpayload voldoende context om de agent aan de grond te houden of moet de agent extra opzoekopdrachten uitvoeren voordat deze effectief kan redeneren?
• Wat is het verwachte eventvolume en de verwachte frequentie? Eventstromen met hoge doorvoer vereisen scorebeheer om uitputtende gelijktijdige agentlimieten te voorkomen.
• Kan dezelfde event meer dan één maal worden geactiveerd voor dezelfde bedrijfsentiteit (ten minste één maal geleverd)? Dan moeten acties idempotent zijn.
• Is er een menselijk escalatiepad als de agent de event niet autonoom kan oplossen?
• Hoe moet mislukte eventverwerking zichtbaar worden? Met een wachtrij voor dode letters, een waarschuwing of het maken van cases?

Toepassing Salesforce-patroon

Schets

Sequentiediagram voor Eventgestuurde agentuitvoering

Resultaten

Agenten worden reactieve deelnemers aan realtime bedrijfsactiviteiten, niet passieve responders op menselijke verzoeken. Door events geactiveerde agenten kunnen herstel-, triage- en escalatiewerkstromen uitvoeren met de snelheid van gegevens in plaats van de snelheid van menselijke aandacht.

Het triggersysteem (Data 360 of platformevents) blijft verantwoordelijk voor eventdetectie en het vormen van payloads. De agent blijft verantwoordelijk voor het redeneren over die payload en het selecteren van de juiste actieketen. Er is geen gespreksbeurt vereist; de eventpayload is de volledige invoer.

Overwegingen bij ontwerpen

Platformonafhankelijke begeleiding

• Ontwerp alle acties voor niet-gespreksaanroep. Er is geen gebruikersbeurt; de agent moet alleen vanuit de initiële aardingscontext een oplossing vinden. Acties moeten gestructureerde, deterministische output retourneren in plaats van vragen om verduidelijking.
• Zorg ervoor dat de eventpayload voldoende aardingscontext bevat voordat de agentsessie wordt gemaakt. Een magere payload die de agent dwingt om meerdere opzoekaanroepen te doen voordat deze kan redeneren, verhoogt de latentie en het gelijktijdige verbruik.
• Maak alle schrijfbewerkingen die worden geactiveerd door eventgestuurde agenten, idempotent. Eventleveringssystemen bieden doorgaans minstens één keer garanties. Verwerking van duplicaatevents kan geen duplicaatbijwerkingen veroorzaken.

Implementatienotities voor Salesforce

• Wijs in Door Data 360 geactiveerde stromen eventpayloadkenmerken (bijvoorbeeld “accountId”, “eventType”, “metricValue”, “productIds”) rechtstreeks toe aan benoemde sessievariabelen op het moment dat de sessie wordt gemaakt. Hierdoor wordt de agent gefundeerd vanaf de eerste redeneringsstap zonder dat er een ophaalactie nodig is.
• Gebruik voor platformeventtriggers een automatisch gestarte stroom in plaats van een schermstroom. Schermstromen worden niet ondersteund in autonome, niet-gesprekscontexten.
• Stel een expliciete sessietime-out in voor door events geactiveerde sessies. In tegenstelling tot gesprekssessies is er geen gebruiker om de interactie uit te breiden. Een sessie die vastloopt op een mislukte actie, mag niet voor onbepaalde tijd een gelijktijdig tijdstip bevatten.
• Gebruik stroomfoutpaden om fouten bij het maken van agentsessies af te handelen. Als de sessie niet kan worden gemaakt, moet het fouttraject een compenserende event publiceren of een case maken voor menselijk vervolg in plaats van de event stilletjes te laten vallen.

Foutafhandeling en herstel

• Events die een agentsessie niet met succes activeren als gevolg van gelijktijdigheidslimieten, fouten bij het maken van een sessie of fouten bij het valideren van payloads, moeten naar een fouttraject worden gerouteerd dat een case maakt, een waarschuwing activeert of de event naar een wachtrij met dode letters publiceert voor herverwerking.
• Mislukte agenten halverwege de uitvoering (bijvoorbeeld time-out van een vereiste actie) moeten worden vastgelegd met de oorspronkelijke event-ID. Aangezien de triggering asynchroon is en er geen beller in de wachtrij is, is het foutoppervlak volledig gebaseerd op observatie: logboeken, dashboards en waarschuwingsdrempelwaarden.
• Implementeer een plafond voor opnieuw proberen. Als een event op betrouwbare wijze agentfouten veroorzaakt, raken onbeperkte pogingen uitgeput. Routeer de event na een configureerbaar maximaal aantal pogingen naar een wachtrij voor menselijke beoordeling met volledige context bijgevoegd.
• Houd de event-ID bij gedurende de volledige levenscyclus van de agentsessie. Dit bijhouden maakt correlatie mogelijk tussen het signaal van de oorspronkelijke gegevens en alle acties verderop in de stroom voor controle en foutopsporing.

Beveiligingsoverwegingen

• Valideer en zuiver alle eventpayloadkenmerken voordat u ze injecteert als agentsessievariabelen. Eventpayloads van Data 360 of externe uitgevers vormen een aanvalsoppervlak voor snelle injectie. Zo kan een vervaardigd payloadveld worden ontworpen om instructies van agenten te overschrijven.
• Voer door events geactiveerde agentsessies uit onder een speciale integratiegebruiker met de minste rechten in plaats van een beheerdersidentiteit met hoge rechten. De agent heeft alleen de machtigingen die vereist zijn voor het uitvoeren van de gedefinieerde actieset.
• Leg alle door events geactiveerde sessies vast met de oorspronkelijke event-ID, het eventtype en de sessievariabelen die bij het maken worden geïnjecteerd. Dit controletraject is verplicht om te reconstrueren waarom de agent een bepaalde actie heeft ondernomen als de uitkomst wordt betwist.

Voorbeeld

Een detailhandelsbedrijf gebruikt Data 360 voor het bijhouden van realtime gedrag van winkelwagentjes. Wanneer een winkelwagentje met een waarde boven een gedefinieerde drempelwaarde wordt verlaten:

1. Data 360 detecteert het verlatingssignaal en activeert een geactiveerde stroom met de eventpayload: “customerId”, “cartValue”, “productIds” en “abandonmentTimestamp”.
2. De stroom wijst deze kenmerken toe aan Agentforce sessievariabelen en maakt een nieuwe agentsessie. Er is geen gebruikersinteractie vereist.
3. De agent evalueert de aankoophistorie, huidige rechten en samenstelling van het winkelwagentje van de klant met behulp van de beschikbare ophaalacties.
4. De agent roept een SelectRecoveryOffer aan, die de juiste kortingslaag toepast op basis van het klantsegment, en een SendProactiveNotification om de aanbieding te leveren via het voorkeurskanaal van de klant.
5. De agent roept CreateFollowUpTask aan om de interactie vast te leggen in het CRM voor de zichtbaarheid van de accounteigenaar.
6. De sessie wordt automatisch gesloten nadat de actieketen is voltooid. De oorspronkelijke event-ID wordt bewaard in het sessielogboek voor traceerbaarheid.

Context

LLM’s worden getraind op basis van openbare gegevens. Ze hebben geen Knowledge van de producten, beleidsvormen, casehistorie of contracten van uw organisatie, tenzij die informatie expliciet wordt verstrekt op het moment van redeneren. Zonder huisarrest hallucineert een agent die vraagt naar het servicerecht van een klant of de voorwaarden van een specifiek contract, een antwoord of geeft deze toe dat deze het niet weet. Geen van beide uitkomsten is acceptabel in een ondernemingscontext.

Retrieval-Augmented Generation (RAG) lost dit op door relevante documenten op te halen uit een Enterprise Knowledge Store en deze in het contextvenster van de agent te injecteren voordat deze een respons genereert. De agent redeneert over opgehaalde inhoud zoals een Knowledge artikel, een oplossing van een case uit het verleden, een productspecificatie alsof deze informatie rechtstreeks is gegeven. De LLM levert de redenering; de ophaallaag levert de feiten.

Een serviceagent die een complexe garantieclaim afhandelt, hoeft bijvoorbeeld geen garantiebeleidsvoorwaarden in zijn instructies te hebben. In plaats daarvan voert de agent, wanneer de klant het probleem beschrijft, een semantische zoekopdracht of hybride zoekopdracht (zoeken op trefwoorden + semantische zoekopdracht) uit op basis van een vectorindex van garantiedocumentatie, haalt de van toepassing zijnde termen op en gebruikt deze om de aanspraak en de volgende stappen te bepalen. Het antwoord is gebaseerd op het huidige, gezaghebbende beleidsdocument, niet op de trainingsgegevens van het model.

Probleem

Een agent moet een vraag beantwoorden of een beslissing nemen die afhankelijk is van gepatenteerde organisatorische Knowledge zoals polissen, contracten, productdocumentatie of historische casegegevens die geen deel uitmaakten van de trainingsgegevens van de LLM. Hoe haalt de agent de meest relevante inhoud op tijdens het redeneren, zorgt hij ervoor dat de opgehaalde inhoud actueel en gezaghebbend is, en injecteert hij deze met voldoende precisie in context om ruis te voorkomen?

Krachten

Beantwoord bij het toepassen van dit patroon de volgende vragen

• Is de Knowledge inhoud statisch en wordt deze niet af en toe bijgewerkt (bijvoorbeeld producthandleidingen) of verandert deze voortdurend (bijvoorbeeld case-oplossingen, voorraadbeschrijvingen)? De updatefrequentie bepaalt het ontwerp van de opnamepijplijn.
• Hoe groot is de inhoud? Een kleine Knowledge base kan uitputtend worden opgehaald; een grote vereist blokken, inbedden en semantische indexering om alleen de meest relevante passages te retourneren.
• Heeft de query baat bij één gerichte ophaalactie of zou het combineren van resultaten uit meerdere Knowledge bronnen (bijvoorbeeld documentatie en cases uit het verleden tegelijkertijd) een beter onderbouwd antwoord opleveren? Dit laatste vereist ensemble retrieval.
• Is het nodig om opgehaalde inhoud te filteren op metagegevens voordat er een semantische plaatsing plaatsvindt, bijvoorbeeld door resultaten te beperken tot documenten die relevant zijn voor de productlaag of geografie van de klant?
• Hoe gevoelig is de Knowledge inhoud? Opgehaalde inhoud wordt geïnjecteerd in het contextvenster van de LLM en beïnvloedt de reactie van de agent. Inhoud die niet zichtbaar mag worden gemaakt voor bepaalde gebruikers, moet worden bepaald op de ophaallaag en mag niet worden geacht te zijn gefilterd door de LLM.

Toepassing Salesforce-patroon

Schets

Sequentiediagram voor Knowledge Grounding vanuit Enterprise Content

Resultaten

De responsen van de agent zijn verankerd aan de huidige, gezaghebbende Knowledge van de organisatie in plaats van de trainingsgegevens van de LLM. Hallucinatierisico voor feitelijke vragen zoals polisvoorwaarden, productspecificaties, rechtendetails wordt verminderd omdat het model redeneert over opgehaald bewijs, niet genereert uit het geheugen.

De Knowledge content blijft onafhankelijk onderhoudbaar. Het bijwerken van een beleidsdocument of het toevoegen van een nieuwe caseoplossing aan de index wordt onmiddellijk van kracht voor alle daaropvolgende agentinteracties, zonder het model opnieuw te trainen of opnieuw te implementeren.

Ophalen biedt ook een impliciet controletraject. Omdat het antwoord van de agent is afgeleid van specifieke opgehaalde documenten, kan de broninhoud naast het antwoord worden vastgelegd, waardoor kan worden getraceerd waarom de agent een bepaald antwoord heeft gegeven.

Overwegingen bij ontwerpen

Platformonafhankelijke begeleiding

• Splits Knowledge content op in de juiste fijnkorreligheid en bed deze in. Brokken die te groot zijn, verwateren de relevantie. Brokken die te klein zijn, verliezen de omringende context die de LLM nodig heeft om correct te redeneren. Voor de meeste typen ondernemingsdocumenten levert het opdelen op alineaniveau met overlappende contextvensters de beste ophaalkwaliteit op.
• Behandel precisie bij het ophalen als een eersteklas ontwerpprobleem. Het injecteren van inhoud met een lage relevantie in het contextvenster van de agent is niet neutraal. Het introduceert ruis die de responskwaliteit verslechtert. Stem drempelwaarden voor ophalen en maximale limieten af om terugroeping af te wegen tegen precisie voor elk Knowledge domein.
• Opnamelatentie is een operationele SLA. Als een beleidsdocument wordt bijgewerkt, maar de vectorindex niet is vernieuwd, haalt de agent verouderde informatie op en handelt deze op basis daarvan. Definieer acceptabele stalenesstolerantie voor elk type inhoud en ontwerp opnamepijplijnen dienovereenkomstig.

Implementatienotities voor Salesforce

• Vul Data 360-vectorindexen in via de juiste opnamepijplijn voor de frequentie van de inhoudsupdate. Gebruik batchgewijs opnemen voor statische documenten en streaming of Change Gegevensvastlegging (CDC) voor records die continu veranderen.
• Configureer voor Ensemble Retrievers de wegingen voor relevantiebeoordeling per bron. Een index van opgeloste cases heeft mogelijk een recente vertekening nodig; een index van beleidsdocumentatie niet. Stem gewichten af op basis van de querytypen die de agent geacht wordt te verwerken.
• Gebruik filters voor metagegevens in aangepaste Apex of stroomophaalprogramma’s om het bereik op te halen voordat semantische zoekopdrachten worden uitgevoerd. Filteren op productlijn, regio of documenttype vóór plaatsing vermindert ruis en verbetert de precisie van wat in context wordt geïnjecteerd.
• Injecteer het volledige opgehaalde document niet in de LLM-context. Geef alleen de relevante blokken of uittreksels door. Grote contextinjecties verbruiken tokenbudget, verhogen de latentie en reduceren het deel van de contextperiode dat beschikbaar is voor de redenering van de agent.

Foutafhandeling en herstel

• Als het ophalen geen resultaten oplevert, retourneert u een expliciete status “geen resultaten gevonden” in plaats van ongegrond door te gaan. De agent kan de query vervolgens uitbreiden, de gebruiker om uitleg vragen of escaleren naar een mens.
• Elk geretourneerd deel van de retrievers bevat een relevantiescore. Afhankelijk van de gebruikscase moet een bepaalde drempelwaarde voor vertrouwen/relevantie worden geconfigureerd waarboven de agent het ophalen als vertrouwenwekkend moet behandelen, anders moet deze terugvallen op verduidelijking of escalatie.
• Als de vectorindex of ophaalservice tijdelijk niet beschikbaar is, moet de actie retriever of Apex aanroep een gestructureerde fout met een beschrijvende reden retourneren. Leg de fout vast met de sessie-ID en query, zodat hiaten in het ophalen kunnen worden geïdentificeerd en de index of service kan worden bewaakt op beschikbaarheid.
• Implementeer voor tijdgevoelige Knowledge domeinen een versheidscontrole als onderdeel van de ophaalrespons. Als het recentste overeenkomende document voor het laatst is bijgewerkt boven een gedefinieerde drempelwaarde voor staleness, signaleert u dit bij de agent zodat deze diens reactie of aanwijzing kan kwalificeren voor verificatie.

Beveiligingsoverwegingen

• Het ophalen moet de machtigingen voor gegevenstoegang respecteren van de gebruiker namens wie de agent optreedt. Een agentsessie die wordt uitgevoerd in de context van een klantgerichte interactie, mag geen interne operationele documenten, notities over prijsstrategieën of records ophalen waartoe de eindgebruiker anders geen toegang zou hebben. Pas beveiliging op veldniveau en recordniveau toe op de ophaallaag. Vertrouw er niet op dat de LLM gevoelige opgehaalde inhoud achterhoudt.
• Opgehaalde inhoud wordt geïnjecteerd in het LLM-contextvenster en kan van invloed zijn op of worden weergegeven in de reactie van de agent. Behandel elk document in de ophaalinhoud als potentieel zichtbaar voor de eindgebruiker en bepaal het lidmaatschap van inhoud dienovereenkomstig.
• Leg alle ophaalquery’s en de document-ID’s van opgehaalde blokken vast naast de sessie-ID. Dit controletraject maakt een reconstructie mogelijk van het bewijs dat de agent heeft gebruikt bij het reageren, wat mogelijk vereist is voor nalevings-, geschillenbeslechtings- of uitlegbaarheidsverplichtingen.

Voorbeeld

Een financiële dienstverlener handelt een vraag van een klant af over boetes voor vervroegde aflossing voor een spaarproduct met een vaste looptijd:

1. De klant vraagt: “Welke boete zou ik lopen als ik mijn geld zes maanden eerder zou opnemen?”
2. De agent roept een actie Individu ophalen aan die is geconfigureerd op basis van een vectorindex van productvoorwaardendocumenten.
3. De retriever voert een semantische zoekopdracht uit met behulp van de querycontext, zoals producttype en klantaccount, en de specifieke vraag, en retourneert de drie meest relevante documentblokken - de clausule voor vroegtijdige inwisseling, de tabel voor boeteberekening en de uitzonderingen die van toepassing zijn op gevallen van nood.
4. De opgehaalde blokken worden in het contextvenster van de agent geïnjecteerd naast de vraag van de klant.
5. De agent voert een redenering uit over de opgehaalde voorwaarden, identificeert het toepasselijke boetetarief voor de productlaag en inwisseltijdlijn van de klant en retourneert een nauwkeurig, op polissen gebaseerd antwoord, met vermelding van de ingangsdatum van de termen die de agent heeft gebruikt.
6. De document-ID’s van de opgehaalde blokken worden vastgelegd met de sessierecord voor controle.

Context

LLM’s zijn probabilistisch van aard. Wanneer hen wordt gevraagd om te redeneren over een specifieke klant, leiden ze feiten af, schatten ze deze in of hallucineren ze feiten die ze niet expliciet hebben gekregen. Een agent die een prijsactie aanroept zonder te weten dat de klant een ondernemingsaccount van hoge waarde is op een voorkeurslaag, kan de verkeerde kortingslogica toepassen. Een agent die een ondersteuningscase escaleert zonder de verlooprisicoscore van de klant te kennen, kan de prioriteit van een account die over enkele dagen wordt omgezet, ongedaan maken.

Geverifieerde klantcontextinjectie lost dit op door actie-invoerparameters vooraf in te vullen met geverifieerde, gestructureerde kenmerken uit het gecombineerde profiel voordat de agent een actie aanroept. De agent leidt niet af wat het segment, de levensduurwaarde of de klanttevredenheidstrend (CSAT) van de klant is. Het ontvangt die feiten als aardende input en redenen eroverheen. Dit patroon vermindert het risico op hallucinaties bij klantspecifieke beslissingen en elimineert redundante opzoekaanroepen tijdens de redeneercyclus.

Voordat een prijsagent bijvoorbeeld een actie “GenerateQuote” aanroept, injecteert de configuratie van de subagent automatisch het segment, de laag en de levensduurwaarde van de klant vanuit diens gecombineerde profiel. De actie ontvangt geverifieerde feiten in plaats van uit LLM afgeleide benaderingen en de offerte is verankerd aan de feitelijke commerciële relatie van de klant.

Dit is geen alternatief voor het patroon “Knowledge Grounding from Enterprise Content”. Een goed ontworpen agent kan beide gebruiken: “Knowledge Grounding from Enterprise Content” biedt op documenten gebaseerde Knowledge, terwijl “Verified Customer Context Injection” de identiteit van de klant bepaalt.

Probleem

Hoe zorgt u ervoor dat een agent nauwkeurige, klantspecifieke feiten zoals segment, laag, levenswaarde, verlooprisico of andere profielkenmerken heeft voordat deze actie onderneemt, in plaats van deze feiten op zichzelf te raden?

Krachten

Beantwoord bij het toepassen van dit patroon de volgende vragen:

• Welke actie-invoerparameters vertegenwoordigen klantspecifieke feiten die, indien afgeleid in plaats van afkomstig, onjuiste of inconsistente uitkomsten zouden opleveren?
• Zijn de vereiste profielkenmerken beschikbaar als standaard gecombineerde profielvelden van Data 360 of vereisen ze berekende insights die zijn afgeleid van ruwe gedrags- en transactiegegevens?
• Hoe vaak veranderen de relevante profielkenmerken? Kenmerken zoals verlooprisicoscore of CSAT-trend vereisen een versheidsgarantie; verouderde profielgegevens leiden tot dezelfde onjuiste uitkomsten als hallucinatiegegevens.
• Moeten profielkenmerken worden geïnjecteerd op het moment dat de sessie wordt gemaakt (constante voor de duur van de sessie) of opnieuw worden opgehaald op het moment dat de actie wordt aangeroepen (om statuswijzigingen halverwege de sessie weer te geven)?
• Moet de agent rechtstreeks over de profielkenmerken redeneren of worden deze alleen verbruikt door de actie en ondoorzichtig voor de redeneringslus van de agent?

Toepassing Salesforce-patroon

Schets

Sequentiediagram voor geverifieerde contextinjectie voor klanten

Resultaten

Acties ontvangen geverifieerde, gestructureerde klantfeiten in plaats van via LLM afgeleide benaderingen. De redenering van de agent is gebaseerd op de feitelijke profielstatus van de klant, waardoor het risico op hallucinatie wordt verminderd bij beslissingen waarbij feitelijke nauwkeurigheid de uitkomstkwaliteit bepaalt, zoals prijzen, rechtencontroles, escalatieroutering en retentieaanbiedingen.

Profielaarding vermindert ook de redeneringslatentie. Wanneer de agent geen opzoekgesprekken hoeft uit te voeren om de basiscontext van de klant vast te stellen, is de redeneercyclus korter en wordt gelijktijdigheid verbruikt voor minder beurten.

Het gecombineerde profiel Data 360 blijft de gezaghebbende bron van feiten van klanten. De subagentconfiguratie of verbonden stroom is de integratienaad. De agent is verantwoordelijk voor het redeneren over die feiten en het selecteren van acties, niet voor het betrekken van de feiten zelf.

Overwegingen bij ontwerpen

Platformonafhankelijke begeleiding

• Identificeer alle actie-invoer die risico op hallucinatie inhoudt—waarbij LLM-conferentie een verkeerde uitkomst kan opleveren in plaats van een geverifieerde waarde. Inputs met hallucinatierisico komen in aanmerking voor profielaarding. Niet elke invoer vereist aarding; overmatige injectie van profielgegevens voegt ruis toe aan het contextvenster van de agent.
• Beschouw profielfrisheid als een ontwerpbeslissing, niet als een bijzaak. Definieer de acceptabele stalenesstolerantie voor elk geaard kenmerk en kies het injectiemechanisme dienovereenkomstig: toewijzing op sessieniveau voor stabiele kenmerken, op stroom gebaseerde vernieuwing voor vluchtige kenmerken.
• Berekende insights moeten bedrijfslogica coderen, niet ruwe meetgegevens. Een agent redeneert over een verloopRiskScore van 0,87 is effectiever dan een agent redeneert over 14 ruwe gedragssignalen. Bereken de interpretatie in Data 360; geef het resultaat door aan de agent.

Implementatienotities voor Salesforce

• Profielaarding is slechts zo betrouwbaar als de combinatie erachter. Zo is de waarde van het gecombineerde profiel volledig afhankelijk van de kwaliteit van de identiteitsoplossing eerder in het productieproces. Als een klant gefragmenteerde identiteiten heeft in bronsystemen die niet zijn gecombineerd, zijn de profielkenmerken die de agent ontvangt onvolledig of vertegenwoordigen ze slechts een gedeeltelijke weergave (bijvoorbeeld Levenswaarde berekend met gegevens van het ene kanaal, maar niet van het andere).
• Gebruik voor met Data 360 verbonden stromen het element Records ophalen met een filter op de “recordId” of “accountId” van de huidige sessie om alleen de relevante profielrecord op te halen. Retourneer alleen de kenmerken die vereist zijn voor de actie verderop in de stroom; retourneer niet het volledige profielobject.
• Berekende insights moeten actueel worden gehouden via Data 360-opnamepijplijnen. Stel streaming of vrijwel realtime vernieuwing in voor insights die worden gebruikt bij tijdgevoelige beslissingen (bijvoorbeeld verlooprisico in een bewaarwerkstroom). Batchgewijs vernieuwde insights zijn acceptabel voor kenmerken met een tragere ontwikkeling (bijvoorbeeld waardelaag voor jaarcontracten).
• Valideer dat toegewezen profielkenmerken niet-null zijn voordat de actie wordt aangeroepen. Een null “customerTier” die wordt doorgegeven aan een prijsactie, is net zo schadelijk als een gehallucineerde waarde. Gebruik stroombeslissingselementen om ontbrekende profielgegevens te detecteren en te routeren naar een reserve die een standaardinstelling ophaalt of aanwijzingen geeft voor verduidelijking.
• Wijs in de configuratie van de subagent profielkenmerken toe aan actie-invoerparameters met behulp van beschrijvende, semantisch duidelijke variabelennamen (bijvoorbeeld “customerTier”, “lifetimeValueUSD”, “churnRiskScore”). De LLM leest deze namen bij het selecteren en samenstellen van acties; ambigue namen verminderen de nauwkeurigheid van de selectie.

Foutafhandeling en herstel

• Als een verplicht profielkenmerk null of onbeschikbaar is op het moment van het aanroepen van de actie, moet de agent niet doorgaan met een potentieel onjuiste standaardinstelling. De actie moet een gestructureerde fout retourneren die het ontbrekende kenmerk aangeeft, terwijl de agent de gebruiker om uitleg moet vragen of moet escaleren naar een mens als deze niet in gesprek is.
• Als een met Data 360 verbonden stroom er niet in slaagt om profielgegevens op te halen (bijvoorbeeld vanwege een onderbreking van de Data 360-service), moet het defectenpad van de stroom een gestructureerde fout retourneren naar de agent met de specifieke reden voor het mislukken. De agent kan dan beslissen of hij het opnieuw probeert, doorgaat met een verslechterde ervaring of de fout zichtbaar maakt voor de gebruiker.
• Leg alle profielkenmerkwaarden vast die worden geïnjecteerd bij het maken van de sessie of het aanroepen van de actie, naast de sessie-ID. Dit zorgt ervoor dat elke betwiste agentbeslissing kan worden gereconstrueerd met de exacte klantfeiten die de agent op dat moment heeft gekregen.

Beveiligingsoverwegingen

• Profielkenmerken die worden geïnjecteerd in agentcontext, zijn onderworpen aan dezelfde besturingselementen voor gegevenstoegang als elke CRM-record. Zorg ervoor dat de integratiegebruiker of verbonden app die wordt gebruikt voor het oplossen van profielkenmerken, alleen de machtigingen op veldniveau heeft die vereist zijn voor de kenmerken die zichtbaar worden gemaakt, en niet de bredere leestoegang voor profielen.
• Berekende insights die gevoelige afgeleide meetgegevens coderen (bijvoorbeeld voorspelde gezondheidsscore, financiële risicolaag) moeten worden behandeld als gevoelige velden en worden beheerd door dezelfde toegangselementen als de onderliggende gegevens. Het naar boven halen van een hoge verlooprisicoscore voor een agent die opereert in een klantgerichte context vereist zorgvuldige overweging van wat de agent kan communiceren.
• Maak geen profielkenmerken zichtbaar die niet vereist zijn door de actie. Elk extra kenmerk in het contextvenster van de agent is een extra gegevenselement dat kan worden gereproduceerd in de reactie van de agent. Pas een minimaal noodzakelijk principe toe op profielaarding.
• Controleer alle sessies waarin Berekende insights of kenmerken van gevoelige profielen zijn geïnjecteerd als invoer. Deze sessies vertegenwoordigen beslissingen die worden genomen op basis van afgeleide Klantenintelligence en kunnen onderworpen zijn aan uitlegbaarheids- of wettelijke vereisten in bepaalde sectoren.

Voorbeeld

Een telecommunicatiebedrijf gebruikt Agentforce voor het afhandelen van bewaargesprekken met klanten die een annuleringsverzoek hebben geïnitieerd.

• Wanneer een annuleringscase wordt geopend, wordt de agentsessie gemaakt met de “accountId” van de klant als context.
• De configuratie van de subagent wijst drie kenmerken van het gecombineerde Data 360-profiel toe aan sessievariabelen op het moment van maken: “customerTier” (Enterprise), “lifetimeValueUSD” (42.000) en “contractRenewalDate” (60 dagen).
• Een Berekende insight zoals “churnRiskScore” (0,91, berekend op basis van gebruiksdaling, ondersteuningsticketfrequentie en NPS-trend) wordt toegewezen als een extra sessievariabele via een via Data 360 verbonden stroom die als de eerste actiestap wordt aangeroepen.
• De agent, die nu is gebaseerd op geverifieerde klantfeiten, roept een actie “SelectRetentionOffer” aan. Omdat de invoer “customerTier = Enterprise”, “lifetimeValueUSD = 42000” en “churnRiskScore = 0.91” omvat, retourneert de actie het maximale retentieaanbod in plaats van een standaardaanbod.
• De agent roept “PresentOffer” aan om het aanbod in het gesprek te leveren en “LogRetentionAttempt” om de interactie in het CRM vast te leggen met alle gegronde kenmerken behouden voor controle.

Context

Enterprise-gegevens zijn gefragmenteerd. Een agent die alleen kan reageren op wat er leeft binnen het Salesforce-platform, is beperkt tot een fractie van de informatie die nodig is om effectief te redeneren. Voor het beantwoorden van een servicevraag moet u mogelijk het open ticket van een klant lezen in Service Cloud. Voor het voorbereiden van een voorstel moet u mogelijk een bestand ophalen uit Google Drive. Voor het analyseren van productgebruik moet u mogelijk een query uitvoeren op een gegevensmagazijn. Elk van deze systemen heeft zijn eigen API’s, een eigen authenticatiemodel en een eigen gegevensschema. De kosten van het schrijven van op maat gemaakte integratiecode voor elk systeem zijn wat agent-naar-systeemconnectiviteit historisch gezien duur en fragiel heeft gemaakt.

MCP is een open standaard die dit direct aanpakt. Het definieert een uniforme interface waarmee een agent tools kan ontdekken en aanroepen die beschikbaar zijn op elke MCP-compatibele server, ongeacht het onderliggende systeem. Elke MCP-server fungeert als een adapter: deze wikkelt de native interfaces van een doelsysteem in een gestandaardiseerde, toolgerichte interface die de agent kan opvragen, aanroepen en samenstellen zonder iets te weten over de specifieke protocollen of schema’s van het systeem.

Vanuit het perspectief van de agent zien het verbinden met Slack, een SQL-database (Structured Query Language) en een documentbeheersysteem er identiek uit, drie MCP-servers die elk een set beschreven, aanroepbare tools weergeven. De agent selecteert en zet ze in een volgorde op basis van hun semantische beschrijvingen en het doel dat ermee wordt nagestreefd.

Probleem

Wanneer een agent informatie moet ophalen of acties moet activeren binnen meerdere externe systemen - elk met verschillende API’s, authenticatie en schema’s - hoe kan deze dan zijn mogelijkheden ontdekken, aanroepen en samenstellen zonder op maat gemaakte integratiecode per systeem of nauwe koppeling met de implementatie van een systeem?

Krachten

Beantwoord bij het toepassen van dit patroon de volgende vragen:

• Moet de agent toegang krijgen tot systemen buiten het Salesforce Platform, zoals documentstores, samenwerkingstools, databases en externe SaaS, waarvan de API’s niet standaard worden voorgesteld als Agentforce acties?
• Is ontdekking van dynamische tools vereist, waarbij de agent het juiste integratie-eindpunt identificeert op basis van het huidige verzoek, in plaats van integraties hardcoded in de configuratie ervan te hebben?
• Verandert het integratielandschap regelmatig; nieuwe systemen die worden toegevoegd, bestaande die worden bijgewerkt en andere wijzigingen kunnen dusdanig vereisen dat een op maat gemaakte aanpak per systeem niet-duurzame onderhoudsoverhead zou creëren?
• Is het nodig om de redeneringslaag van de agent los te koppelen van de implementatiedetails van downstream systemen, zodat een wijziging in de API van een doelsysteem geen wijzigingen in de instructies of subagentconfiguratie van de agent vereist?
• Zijn de doelsystemen eigendom van verschillende teams of leveranciers, die elk verantwoordelijk zijn voor het zichtbaar maken van hun eigen mogelijkheden, waardoor een MCP Server-model aan de providerzijde praktischer is dan een integratie aan de consumentzijde per agent?

Toepassing Salesforce-patroon

Schets

Sequentiediagram voor geverifieerde contextinjectie voor klanten

Resultaten

Het bereikbare oppervlak van de agent wordt groter zonder de integratiecomplexiteit ervan te vergroten. Het toevoegen van een nieuw extern systeem betekent dat u er een MCP Server voor implementeert of configureert en geen op maat gemaakte Apex aanroepen of stroomintegraties per agent schrijft. De redeneringslaag van de agent blijft ongewijzigd; deze ontdekt en roept de nieuwe tools alleen aan op basis van hun semantische beschrijvingen.

De MCP-standaard zorgt ook voor een zuivere scheiding van eigendom: het team dat verantwoordelijk is voor een systeem, toont zijn mogelijkheden als een MCP-server; het agentteam verbruikt die mogelijkheden zonder de interne aspecten van het systeem te hoeven begrijpen. Deze grens vermindert de coördinatie-overhead naarmate het aantal geïntegreerde systemen groeit.

Samenstelbaarheid van gereedschap is een directe uitkomst. Omdat alle tools dezelfde aanroepinterface hebben, kan de agent tools uit verschillende systemen koppelen, een bestand ophalen uit Google Drive, er gegevens uit extraheren en het resultaat net zo natuurlijk naar een CRM-record schrijven als het koppelen van acties binnen één systeem.

Overwegingen bij ontwerpen

Platformonafhankelijke begeleiding

• Toolbeschrijvingen vormen de enige basis voor de agent om te beslissen of en hoe een tool wordt aangeroepen. Schrijf beschrijvingen in duidelijke, op intents gebaseerde taal waarin wordt vermeld wat de tool doet, wanneer deze van toepassing is en wat deze retourneert. Een beschrijving met de tekst “query’s uitvoeren op de CRM-database” is minder nuttig dan “haalt de open cases van de account op, gerangschikt op prioriteit, voor een bepaalde account-ID”. Slechte beschrijvingen leiden tot een slechte toolselectie.
• Bereik elke MCP-tool tot één atomaire mogelijkheid. Een tool die een document ophaalt en ook een samenvatting terugschrijft naar het bronsysteem, is moeilijker te redeneren voor de agent, moeilijker opnieuw te proberen bij mislukking en moeilijker te beveiligen dan twee afzonderlijke tools. Eén tool, één verantwoordelijkheid.
• Ontwerp tools zodat uitvoer samenstelbare invoer is. Het resultaat van een ophaaltool moet op een natuurlijke manier worden toegewezen aan de invoerparameters van de actietools die er doorgaans op volgen, waardoor het transformatiewerk dat de agent tussen stappen moet uitvoeren, wordt verminderd.
• MCP-servers op afstand hosten. Lokale binaire installaties creëren complexiteit bij implementatie en versiebeheer, die groeit met het aantal agentomgevingen. Een extern gehoste server kan worden bijgewerkt onafhankelijk van de agenten die deze gebruiken.

Implementatienotities voor Salesforce

• Als u consistente MCP-authenticatie, scorelimiet en payloadvalidaties wilt voor alle uitgaande MCP-aanroepen, gebruikt u AI Gateway zoals MuleSoft Omni Gateway die MCP-servers ondersteunt en configureert u deze voordat u een MCP-server aan agenten blootstelt.
• Gebruik OAuth 2.0-inloggegevens voor alle inloggegevens die vereist zijn voor MCP Server-verbindingen. Inloggegevens mogen niet voorkomen in toolparameters, actieconfiguraties of Apex code.
• Sommige MCP-tools hebben mogelijk inloggegevens van eindgebruikers nodig om bepaalde acties te kunnen ondernemen, afhankelijk van de zakelijke gebruikscase (zoals fondsoverdracht). Als u identiteitstokens van eindgebruikers wilt propageren, gebruikt u het beleid OAuth 2.0 On Behalf Of Credentials Injection, dat momenteel wordt ondersteund met MuleSoft Omni Gateway.
• Voor aangepaste MuleSoft MCP-servers: definieer het MCP-toolschema in de API-specificatie van MuleSoft en registreer het eindpunt van de server in de Agentforce toolcatalogus. Test toolbeschrijvingen aan de hand van representatieve agentquery’s om te controleren of de agent de juiste tool voor de juiste taak selecteert voordat deze naar productie wordt geïmplementeerd.

Foutafhandeling en herstel

• Wanneer een MCP-toolaanroep een fout retourneert, inspecteert de agent de machineleesbare foutcode om de juiste herstelactie te bepalen: ontbrekende parameters aanvragen bij de gebruiker, opnieuw proberen met gecorrigeerde invoer of escaleren naar een mens. Het verbruikt nooit stilzwijgend fouten of gaat door met redeneren alsof de toolaanroep is geslaagd.
• De agent implementeert logica voor opnieuw proberen voor tijdelijke storingen rechtstreeks.
• Leg elke aanroep van een MCP-tool vast vanaf de clientzijde met de toolnaam, gesanitiseerde invoerparameters en de uitkomst. Deze tracering aan clientzijde in combinatie met logboeken aan serverzijde is het primaire mechanisme om te bepalen waarom een agent een bepaald actiepad heeft genomen wanneer een werkstroom niet het verwachte resultaat oplevert.

Beveiligingsoverwegingen

• Alle uitgaande MCP-serververbindingen gaan via de gateway. De gateway dwingt authenticatieverificatie, snelheidsbeperkingen om misbruik van tools te voorkomen en inspectie van payloads af om prompte injectiepogingen in toolparameters te detecteren. Directe, niet-gemedieerde verbindingen van agenten met MCP-servers omzeilen deze besturingselementen en zijn niet toegestaan.
• Bereik de MCP-serververbindingen van elke agent tot alleen de servers waarvan de agent de tools daadwerkelijk nodig heeft. Een agent die is geconfigureerd met toegang tot alle beschikbare MCP-servers, heeft een groter aanvalsoppervlak dan één agent die alleen is verbonden met de tools die zijn gedefinieerde taken vereisen.
• Valideer en zuiver toolinvoerparameters voordat u ze doorgeeft aan de tool, met name wanneer parameterwaarden zijn afgeleid van door de gebruiker aangeleverde tekst of door LLM gegenereerde inhoud. Geef niet-gevalideerde LLM-uitvoer niet rechtstreeks door als toolparameters; een aanvaller die de redenering van de agent kan beïnvloeden, kan dat pad gebruiken om kwaadaardige waarden in te brengen in systeemaanroepen verderop in de stroom.
• Behandel de lijst van verbonden MCP-servers van de agent en hun gereedschapsvoorraden als gevoelige configuratie. Een aanvaller die weet welke tools een agent beschikbaar heeft en welke parameters deze accepteert, heeft een kaart voor het maken van prompt injectiepayloads die zijn ontworpen om misbruik te maken van die tools.

Voorbeeld

Een verkoopagent bereidt een uitgebreide accountbriefing voor voorafgaand aan een hoogwaardig klantgesprek:

1. De agent ontvangt het verzoek: “Bereid een briefing over Acme Corp voor op de verlengingsbespreking van morgen.”
2. De agent voert een query uit op de MCP-toolcatalogus en identificeert drie relevante tools op twee MCP-servers: GetRecentEmails, GetOpenOpportunities en GetSupportTicketSummary.
3. De agent roept alle drie de tools parallel aan. Elke MCP-server vertaalt de aanroep naar de native API van het doelsysteem, haalt de relevante gegevens op en retourneert een gestructureerd resultaat.
4. De agent ontvangt de drie resultaten. Recente e-mailthreads, de open verlengingsopportunity met dealgrootte en -fase, en een samenvatting van open ondersteuningstickets op prioriteit, en synthetiseert deze in een gestructureerde accountbriefing.
5. De agent roept CreateAccountNote aan om de briefing op te slaan in de accountrecord en retourneert een samenvatting naar de aanvragende gebruiker.
6. Alle vier MCP-toolaanroepen worden door de gateway vastgelegd met toolnamen, serveridentiteiten en uitkomsten voor de sessieauditrecord.

Context

Het uitgaande MCP-patroon beschrijft een Agentforce agent die tools verbruikt van externe MCP-servers. Het inkomende patroon draait dit om. Salesforce Platform-mogelijkheden zoals CRM-records, stromen, Apex logica en Data 360-insights worden zichtbaar als MCP-tools die externe agenten, die op elk LLM-framework worden uitgevoerd, kunnen ontdekken en aanroepen.

Dit patroon is belangrijk omdat AI-implementaties voor ondernemingen zelden door één leverancier worden uitgevoerd. De agent van een partner die is samengesteld op basis van een ander framework, moet mogelijk de accountstatus van een klant opzoeken in Salesforce. Een intern Data Science-team dat een op Python gebaseerde agent uitvoert, moet mogelijk een Salesforce-stroom activeren om een goedkeuringsproces te starten. Zonder een gestandaardiseerd blootstellingsmechanisme vereist elke externe consument een integratie op maat. Als Salesforce-mogelijkheden worden weergegeven als een MCP-server, krijgt elke MCP-compatibele agent een uniforme, detecteerbare interface naar de tools van het platform, ongeacht de manier waarop de aanroepende agent is samengesteld.

Zo moet de inkoopagent van een partner, die is samengesteld op basis van een framework van derden, de contractstatus van een leverancier in Salesforce verifiëren voordat een inkooporder wordt goedgekeurd. In plaats van een directe REST-integratie te bouwen, roept het een GetContractStatus tool aan op de Salesforce MCP Server. De tool dwingt dezelfde toegangscontroles af als elke eigen Salesforce-bewerking; de aanroepende agent ziet alleen het resultaat.

Probleem

Wanneer een externe agent die is gebouwd op een ander framework, eigendom is van een partner of anderszins buiten het Salesforce-platform wordt uitgevoerd, Salesforce-mogelijkheden moet aanroepen als onderdeel van zijn eigen werkstroom, hoe kunnen die mogelijkheden dan worden blootgesteld op een gestandaardiseerde, detecteerbare en veilig beheerde manier die geen op maat gemaakte integratie per externe consument vereist?

Krachten

Beantwoord bij het toepassen van dit patroon de volgende vragen:

• Zijn de externe agenten die Salesforce-mogelijkheden moeten verbruiken, gebaseerd op frameworks die de MCP-standaard ondersteunen? Als dit niet het geval is, is een REST-API of een webhookbenadering wellicht geschikter dan MCP.
• Welke Salesforce-mogelijkheden moeten zichtbaar zijn: alleen-lezen gegevens ophalen, schrijfbewerkingen, stroomaanroepen of een combinatie? De omvang van de blootstelling bepaalt rechtstreeks het te besturen beveiligingsoppervlak.
• Hoe moet de identiteit van de externe aanroepende agent worden geverifieerd en onder welke Salesforce-machtigingen moeten de aanroepen worden uitgevoerd? Agent-naar-platform-aanroepen mogen geen bredere machtigingen overnemen dan de specifieke bewerking vereist.
• Is de Salesforce MCP Server bedoeld voor interne consumenten (agenten van andere teams binnen dezelfde organisatie) of externe consumenten (partner- en klantagenten)? Het Trust model en de authenticatievereisten verschillen aanzienlijk tussen deze doelgroepen.
• Hoe zal de set blootgestelde tools zich ontwikkelen in de loop van de tijd? Nieuwe Salesforce-mogelijkheden die worden toegevoegd aan de MCP Server, worden onmiddellijk ontdekt door alle verbonden agenten; onbedoelde blootstelling aan tools moet worden geregeld via een opzettelijk publicatieproces.

Toepassing Salesforce-patroon

Schets

Sequentiediagram voor zakelijke mogelijkheden als aanroepbare tool

Resultaten

Salesforce wordt een eersteklas deelnemer aan agentecosystemen voor meerdere leveranciers. Externe agenten kunnen platformmogelijkheden ontdekken en verbruiken zonder een aangepaste REST-integratie per consument of per gebruikscase. Het aantal consumenten kan groeien zonder proportionele groei van de overhead voor integratieonderhoud.

Met Headless 360 bepaalt het Salesforce-machtigingenmodel elke inkomende toolaanroep. Externe MCP-clients omzeilen bestaande besturingselementen voor gegevenstoegang niet; ze werken binnen deze besturingselementen. Dit betekent dat de beveiligingspositie van het zichtbaar maken van mogelijkheden via MCP gelijk is aan het zichtbaar maken ervan via een ander geauthenticeerd API-oppervlak.

Ontdekbaarheid van tools is een samengesteld voordeel. Naarmate nieuwe Salesforce-mogelijkheden worden toegevoegd aan de toolcatalogus van de MCP Server, komen ze onmiddellijk beschikbaar voor alle verbonden externe agenten zonder dat deze agenten hun configuraties hoeven bij te werken.

Overwegingen bij ontwerpen

Platformonafhankelijke begeleiding

• Publiceer alleen wat externe agenten nodig hebben. Elke tool die aan de catalogus van de MCP Server wordt toegevoegd, vergroot het aanvalsoppervlak en de governancelast. Controleer doelbewust de voorraad van de tool. Definieer welke mogelijkheden zijn goedgekeurd voor extern verbruik en beschouw niet-goedgekeurde blootstelling als een configuratiehiaat, niet als een standaard.
• Schrijf toolbeschrijvingen voor externe consumenten. De operator van een externe agent heeft geen Knowledge van uw interne gegevensmodel of naamgevingsconventies. Houd beschrijvingen op zichzelf: wat de tool doet, wat elke parameter betekent, wat het resultaat vertegenwoordigt en eventuele beperkingen of randvoorwaarden waaraan de aanroeper moet voldoen.
• Versietools expliciet wanneer hun invoer- of uitvoerschema’s veranderen. Een externe agent die afhankelijk is van het huidige schema van een tool, wordt zonder kennisgeving verbroken als het schema wordt gewijzigd. Behandel wijzigingen in de interface van een MCP-tool met dezelfde discipline als een wijziging in een openbare REST-API.

Implementatienotities voor Salesforce

• Voer elke inkomende Salesforce Out-of-the-Box (OOTB) MCP (Headless 360) toolaanroep uit onder een eindgebruiker wiens machtigingen zijn beperkt tot alleen de bewerkingen die de blootgestelde tools vereisen. Voer geen inkomende agentaanroepen uit onder een beheerdersidentiteit met hoge machtigingen.
• Als u authenticatie, snelheidsbeperking, schemavalidatie en detectie van persoonsgegevens consistent wilt toepassen op alle MCP-tools, gebruikt u AI Gateway zoals MuleSoft Omni Gateway.
• Definieer voor MuleSoft MCP Facades het MCP-toolschema in MuleSoft onafhankelijk van het onderliggende Salesforce API-schema. De MCP-interface moet de conceptuele behoefte van de aanroepende agent weerspiegelen en niet de vorm van het Salesforce-object dat deze ondersteunt. Door deze ontkoppeling kan de Salesforce-implementatie zich ontwikkelen zonder het externe toolcontract te verbreken.

Foutafhandeling en herstel

• Mislukte toolaanroepen moeten gestructureerde MCP-foutresponsen retourneren met een machineleesbare code en een beschrijving in platte taal. De aanroepende externe agent heeft geen zicht op de interne functies van het Salesforce-platform, aangezien foutberichten zelfstandig en bruikbaar moeten zijn zonder Knowledge van Salesforce-specifieke foutcodes of objectmodellen.
• Fouten in de snelheidslimiet en authenticatiefouten moeten onmiddellijk worden geretourneerd met voldoende informatie voor de operator van de externe agent om te kunnen vaststellen welke snelheidslimiet is bereikt of welk inloggegeven is afgewezen zonder interne configuratiedetails zichtbaar te maken.
• Leg alle inkomende MCP-toolaanroepen bij de Omni Gateway vast met de identiteit van de aanroepende agent, de aangeroepen tool, de invoerparameters (opgeschoond van gevoelige waarden) en de uitkomst. Dit logboek is het primaire bewijsspoor voor het diagnosticeren van fouten die zijn gemeld door externe consumenten en voor het controleren van waartoe externe agenten toegang hebben gekregen.

Beveiligingsoverwegingen

• Elke inkomende MCP-verbinding moet worden geverifieerd voordat een tool toegankelijk is. Sta geen ongeauthenticeerde ontdekking van de toolcatalogus toe; de lijst van blootgestelde mogelijkheden is zelf gevoelige informatie.
• Pas autorisatie op toolniveau toe naast authenticatie op verbindingsniveau. Een geregistreerde externe agent moet alleen de specifieke tools kunnen aanroepen waartoe deze expliciet toegang heeft gekregen, niet de volledige catalogus. Dwing dit af bij de gateway, niet bij de toepassingslaag.
• Valideer en zuiver alle inkomende toolparameters voordat u ze doorgeeft aan Salesforce Platform-activiteiten. Parameters van externe agenten vormen een niet-vertrouwd invoeroppervlak. Een kwaadwillig vervaardigde parameter kan proberen om queryfilters te overschrijven, SOQL-fragmenten (Salesforce Object Query Language) te injecteren of stroomvariabelen te beïnvloeden. Valideer type, indeling en bereik op de MCP Server- of gevelgrens.
• Voer een periodieke toegangscontrole uit van geregistreerde externe consumenten. Inloggegevens intrekken voor agenten die niet langer actief zijn of van wie het toegangsbereik is gewijzigd. Een slapend maar geldig inloggegeven voor een buiten gebruik gestelde partnerintegratie is een onnodig risico.
• Bescherm uzelf tegen het schenden van platformlimieten door inkomende MCP-berichten in de gateway te beperken. Beperk het verkeer van niet-kritieke agenten bij belasting met behulp van op SLA’s gebaseerde beleidsvormen voor lagen.

Voorbeeld

Een inkoopagent die wordt geëxploiteerd door een logistieke partner, moet het contract en de kredietstatus van een leverancier verifiëren voordat een inkooporder van hoge waarde wordt goedgekeurd:

1. De agent van de partner authenticeert bij de gateway met behulp van de geregistreerde OAuth 2.0-clientgegevens en ontvangt een toegangstoken met bereik.
2. De agent voert een query uit op de toolcatalogus van Salesforce MCP Server en identificeert twee relevante tools: GetSupplierContractStatus en GetAccountCreditSummary.
3. De agent roept GetSupplierContractStatus aan met de identifier van de leverancier. De MCP-server vertaalt dit naar een Salesforce-recordquery, past de beveiliging op veldniveau van de integratiegebruiker toe en retourneert de huidige status, vervaldatum en eventuele gesignaleerde naleving van het contract.
4. De agent roept GetAccountCreditSummary aan, dat door de MuleSoft MCP-gevel routeert. De gevel aggregeert het openstaande factuursaldo en de betalingshistorie van de leverancier van twee Salesforce-objecten en retourneert één samengestelde kredietsamenvatting.
5. Met beide resultaten bepaalt de agent van de partner dat het contract actief is en de kredietpositie binnen aanvaardbare limieten ligt, en keurt de inkooporder goed in het eigen systeem.
6. Beide toolaanroepen worden door de gateway vastgelegd met de identiteit van de partneragent, de aangeroepen tools en de uitkomsten, waardoor een controleerbare record wordt gemaakt van welke externe toegang is verleend en welke gegevens zijn geretourneerd.

Context

Enterprise-systemen vertrouwen nu op swarms of netwerken van samenwerkende agenten, waarbij complexe verzoeken worden ontbonden en gedelegeerd aan gespecialiseerde agenten in verschillende domeinen of leveranciersplatforms. Deze agenten, elk met hun eigen rol, mogelijkheden en tools, hebben een gestandaardiseerde, veilige communicatiemethode nodig om gedeelde doelen te coördineren zonder menselijke tussenkomst bij elke stap.

Probleem

Hoe kan een aanroepende AI-agent dynamisch complexe of domeinspecifieke taken ontdekken, veilig ermee werken en deze delegeren aan een externe peer-agent die mogelijk is samengesteld op basis van een ander framework of wordt beheerd door een andere leverancier, en gestructureerde resultaten ontvangen om een grotere ondernemingswerkstroom te voltooien?

Krachten

Beantwoord bij het toepassen van dit patroon de volgende vragen:

• Hoe werken agenten, ontwikkeld met behulp van diverse frameworks of werkend binnen silo-applicatiedomeinen, samen?
• Hoe kunnen agenten samenwerken en taken delegeren zonder hun interne logica, geheugen of eigen tools zichtbaar te maken?
• Hoe ondersteunen agenten complexe, langlopende taken terwijl ze realtime statusupdates, streaming en pushkennisgevingen bieden?
• Hoe dwingen agenten beveiliging op ondernemingsniveau (authenticatie, autorisatie) en naleving van beleid af voor communicatie tussen agenten?
• Hoe gaan agenten om met gestructureerde taakwerkstromen (initiatie, voortgang, voltooiing) die verder gaan dan eenvoudige API-aanroepen?

Toepassing Salesforce-patroon

Het A2A-protocol is een open standaard waarmee agenten andere agenten kunnen ontdekken, delegeren aan en samenwerken als peers. Het biedt een gemeenschappelijke taal voor agenten om veilig informatie uit te wisselen en acties te coördineren tussen verschillende platforms en leveranciers. A2A richt zich op peer-to-peer communicatie, als aanvulling op MCP, dat zich richt op het verbinden van agenten met tools en API’s.

Schets

De architectuur houdt in dat een aanroepende agent communicatie initieert, gefaciliteerd door een agentcatalogus/-register voor ontdekking:

Sequentiediagram voor kruisagentdelegatie

De peeragent verwerkt het verzoek met behulp van de domeinspecifieke logica, het geheugen en de tools ervan en retourneert vervolgens gestructureerde resultaten naar de aanroepende agent.

Resultaten

A2A-delegatie scheidt domeineigendom van werkstroomcombinatie. De aanroepende agent hoeft niet te weten hoe de peer-agent is samengesteld, op welk platform deze wordt uitgevoerd of welke tools deze intern gebruikt; de agent delegeert een taak en ontvangt een gestructureerd artefact. Deze grens betekent dat een gespecialiseerde agent (achtergrondverificatie, scoren van financiële risico’s, logistieke routering) kan worden ontwikkeld, geïmplementeerd en verbeterd, onafhankelijk van de werkstromen die deze aanroepen.

Het levenscyclusmodel van de taak van het protocol (ingediend, werkend, voltooid, mislukt) ondersteunt
langlopende bewerkingen native. De aanroepende agent kan zich registreren voor statusupdates in plaats van
dan het vasthouden van een blokkerende verbinding, wat betekent dat A2A-taken minuten of uren kunnen bestrijken
zonder dat de orkestrerende agent gedurende de gehele periode actief moet blijven.

Overwegingen bij ontwerpen

Platformonafhankelijke begeleiding

• In complexe scenario’s kan een agentmakelaar fungeren als een intelligente routeringsservice of “slim schakelbord” om taakdelegatie tussen gespecialiseerde agenten te coördineren en processen met meerdere stappen te beheren.
• Aangezien A2A langdurige taken ondersteunt, moet de communicatie gericht zijn op taakvoltooiing, het definiëren van een levenscyclus voor het taakobject en het bieden van real-time statusupdates en kennisgevingen.
• Het protocol is ontworpen voor ondersteuning van verschillende inhoudstypen, waaronder tekst, bestanden, gestructureerde gegevens, audio- en videostreaming.
• De relaties en afhankelijkheden tussen agenten en hun mogelijkheden worden declaratief gedefinieerd in een configuratiebestand (bijvoorbeeld “agent-network.yaml”) en gepubliceerd in het register van agenten.

Implementatienotities voor Salesforce

• Voor een effectieve SOMA-combinatie houdt u verbonden subagenten onder 7 om de routeringskwaliteit te behouden.
• Momenteel wordt alleen de enkelvoudige delegatielaag ondersteund (superagent → subagent); diepere ketens duwen de latentie naar een “onhoudbare snelheid”. Momenteel kunnen subagenten niet delegeren aan andere verbonden subagenten.
• Menselijke overdracht wordt alleen ondersteund op orchestratorniveau; subagenten kunnen niet escaleren.
• Gebruik binnen SOMA Agent-script wanneer op LLM gebaseerde routering leidt tot verkeerde routering voor ambigue invoer voor deterministische routering. Agentscript schakelt beheerde gedeelde context tussen agenten in.

Foutafhandeling en herstel

Het A2A-protocol definieert uitgebreide foutcodes om robuuste foutopsporing en foutbeheer te vergemakkelijken.

• Herstellogica: Agenten moeten beleid voor opnieuw proberen (opnieuw proberen), failoverlogica naar alternatieve geschikte agenten en expliciete time-outs opnemen.
• Taakstatus bijhouden: De taakbeheerwerkstroom zorgt ervoor dat agenten gesynchroniseerd kunnen blijven met de meest recente status van een taak, waardoor herstel in geval van onderbreking wordt vergemakkelijkt.
• Waarneembaarheid: Het vastleggen van interactiedetails, zoals latentie, successcores en foutfrequenties, is essentieel voor het bewaken van de kwaliteit en het oplossen van problemen.

Beveiligingsoverwegingen

• Enterprise-grade authenticatie: A2A is ontworpen om te voldoen aan authenticatie- en autorisatiestandaarden op ondernemingsniveau, zoals OAuth 2.0 en JWT, die vaak worden beheerd door externe platforms zoals Okta.
• Gateway om A2A te beschermen: Een gateway (bijvoorbeeld MuleSoft Omni Gateway) is essentieel voor het afdwingen van beleidsvormen voor alle A2A-communicatie. Deze gateway fungeert zowel als inkomende als uitgaande gateway om agenten te beschermen en uitgaand verkeer naar externe agenten en services te controleren.
• Beleidshandhaving: Agent Card Rewrite, Schema Validation, Spike Control, PII Detector en andere beleidsvormen moeten worden toegepast voor A2A-server- en gegevensbescherming.

Voorbeeld

Kandidaat-inkoopwerkstroom

Een manager in dienst neemt zijn of haar centrale agent op om kandidaten te vinden die overeenkomen met een vacature en vaardighedenset.

1. Ontdekking: De doeltreffende agent voert een query uit op het agentenregister en ontdekt een gespecialiseerde wervingsagent en een agent voor achtergrondcontrole (beide peer-agenten).
2. Delegatie (A2A): De doeltreffende agent verzendt een gestructureerd taakverzoek (A2A-bericht) naar de wervingsagent om kandidaten te vinden.
3. Verwerking door collega’s: De wervingsagent voert zijn eigen werkstroom uit (bijvoorbeeld een externe LinkedIn-tool aanroepen via MCP).
4. Artefactretour (A2A): De wervingsagent retourneert een lijst van voorgestelde kandidaten (het artefact).
5. Sequentiële delegatie: De doeltreffende agent delegeert vervolgens een andere taak (A2A) aan de achtergrondcontroleagent voor de beste kandidaat. Deze agent voert de controle uit en retourneert het resultaat, waarbij de algemene taak wordt voltooid.

Context

Complexe ondernemingswerkstromen vereisen vaak gespecialiseerde agenten die worden gehost op externe platforms of partnersystemen om taken te initiëren, query’s te delegeren of updates te geven aan interne agenten (bijvoorbeeld die op het Salesforce-platform). Dit patroon behandelt de manier waarop een interne Agentforce agent veilig en betrouwbaar verzoeken van een externe, peer agent ontvangt en verwerkt om een domeinspecifieke mogelijkheid uit te voeren.

Probleem

Hoe kan een interne gespecialiseerde AI-agent (bijvoorbeeld een achtergrondcontroleagent voor Agentforce) zijn domeinspecifieke functionaliteit veilig beschikbaar stellen aan externe peer-agenten, een inkomend, gestructureerd A2A-verzoek verwerken en de taaklevenscyclus (inclusief realtime statusupdates) beheren om gestructureerde artefacten terug te sturen naar de agent die op afstand belt?

Krachten

Beantwoord bij het toepassen van dit patroon de volgende vragen:

• Hoe stelt u de mogelijkheden van interne agenten veilig beschikbaar voor externe agenten zonder de interne logica of tools in gevaar te brengen?
• Hoe dwingt u beveiligingsbeleid op ondernemingsniveau af om de identiteit en gedelegeerde bevoegdheid van de aanroepende agent te verifiëren voordat verzoeken worden verwerkt?
• Hoe gaat u om met langlopende inkomende taken en biedt u gestructureerde, asynchrone statusupdates?
• Hoe zorgt u voor een naadloze interactie met agenten die zijn gebaseerd op diverse, externe frameworks?

Toepassing Salesforce-patroon

Het A2A-protocol biedt de open standaard voor veilige, peer-to-peer delegatie en samenwerking. De interne agent fungeert als de peeragent, adverteert zijn mogelijkheden via een Agentencatalogus/-register en gebruikt A2A via beveiligde kanalen (HTTPS/SSE) om gestructureerde verzoeken te ontvangen en te beantwoorden.

Schets

Sequentiediagram voor agenten als aanroepbare services

Resultaten

Dit patroon maakt interne agenten zichtbaar als gespecialiseerde services binnen een netwerk met meerdere agenten. Externe agenten kunnen taken veilig delegeren aan interne mogelijkheden terwijl de organisatie controle, controleerbaarheid en beleidsafdwinging behoudt.

Overwegingen bij ontwerpen

Platformonafhankelijke begeleiding

• Een gateway (bijvoorbeeld MuleSoft Omni Gateway) moet worden gepositioneerd als een invoerpunt om beleidsvormen, inclusief snelheidslimieten, authenticatie en payloadvalidatie, af te dwingen voor alle inkomende A2A-verzoeken.
• Interne agenten moeten de status van het taakobject beheren van externe initiatie tot voltooiing, zodat de agent die op afstand belt consistente, controleerbare statusupdates ontvangt.
• Zorg ervoor dat de gepubliceerde mogelijkheden van de agent op de agentkaart duidelijk zijn, op intent zijn gebaseerd en de benodigde beveiligingsbereiken voor delegatie bevatten.

Foutafhandeling en herstel

• Gestructureerde foutcodes: Bij mislukking moet de interne agent A2A-conforme gestructureerde foutberichten retourneren naar de aanroepende agent om logica voor opnieuw proberen op afstand of alternatieve failovermechanismen in te schakelen.
• Idempotentie: De agent moet controleren of eventuele bijwerkingen die worden geactiveerd door een opnieuw geprobeerd A2A-verzoek van een externe agent (als gevolg van netwerkonderbreking of herstel), idempotent zijn.

Beveiligingsoverwegingen

• Afdwingen van inkomend beleid: De gateway moet beleidsvormen afdwingen voor het toestaan/blokkeren van de lijst van externe agenten en het valideren van JWT/OAuth 2.0-tokens om de identiteit en gedelegeerde bevoegdheid van de aanroepende agent te verifiëren.
• Invoersanering: Valideer en zuiver alle inkomende verzoekpayloads om potentiële promptinjectie of aanvallen met kwaadaardige gegevens te beperken.
• Identiteitsvoortplanting: Wijs de identiteit van de externe agent en diens gedelegeerde bevoegdheid veilig toe aan interne beveiligingscontexten (bijvoorbeeld Salesforce-gebruikersprofielen) voordat u acties uitvoert tegen interne systemen.

Voorbeeld

Extern systeemonderzoek

1. Verzoek: Een Wervingsagent op een partnersysteem stuurt een A2A-taakverzoek naar een interne medewerkerverificatieagent (peer agent) op Agentforce om de arbeidsstatus van een nieuwe kandidaat te bevestigen.
2. Verwerking: De medewerkerverificatieagent ontvangt het verzoek via de gateway, verifieert de inloggegevens van de partneragent, voert de interne werkstroom ervan uit (bijvoorbeeld een intern HR-systeem aanroepen) en maakt de respons op.
3. Respons: De peer-agent retourneert een gestructureerd A2A-artefact (bijvoorbeeld begindatum en functie) naar de externe wervingsagent, die vervolgens doorgaat met de externe werkstroom.

1. Gateway voor bescherming van MCP’s, A2A’s en API’s

   Een gateway is vereist als het centrale afdwingingspunt voor alle verkeer van agent naar systeem en systeem naar agent.

• Beveiligde verbindingen: Een gateway zorgt ervoor dat alleen geauthenticeerde en geautoriseerde agenten interactie hebben met MCP-, A2A- en API-eindpunten door toegang te beperken.

• Afgedwongen SLA’s: Een gateway kan scorelimieten afdwingen, organisaties helpen te voldoen aan prestatievereisten en overbelasting van MCP- en A2A-servers voorkomen.

• Vereenvoudigde governance: Een gateway biedt gecentraliseerde zichtbaarheid en controle over alle serverinteracties, wat het beheer en de bewaking van agentactiviteiten vereenvoudigt.

• Gegevensconsistentie en -bescherming: Beleidsvormen, zoals schemavalidatie, dwingen gegevensconsistentie af en detectie van persoonsgegevens kan gevoelige informatie beschermen.

MueleSoft Omni Gateway

2. Identiteitspropagatieketen

Naarmate bedrijven het agentische paradigma omarmen, ontstaat er een nieuwe beveiligingsuitdaging: Hoe stroomt de identiteit van eindgebruikers door een netwerk van autonome AI-agenten? In traditionele API-architecturen authenticeert een gebruiker eenmaal en roept de toepassing back-endservices aan namens de gebruiker. De identiteitsketen is kort, goed begrepen en wordt doorgaans beheerd binnen één Trust domein.

Agentische architecturen bieden echter veel langere ketens waarin één verzoek wordt verspreid over verschillende agenten, services en MCP-servers, waarbij elk potentieel servicegrenzen, Trust domeinen en zelfs organisatorische grenzen overschrijdt. Zonder een weloverwogen strategie voor identiteitsverspreiding staan ondernemingen voor de keuze tussen beveiliging en functionaliteit – een dilemma dat geen architect hoeft aan te pakken.

MuleSoft lost de complexiteiten van identiteitsverspreiding op met de voorziening Trusted Agent Identity. Deze oplossing maakt gebruik van een op beleid gebaseerde, door gateways beheerde strategie om ervoor te zorgen dat de identiteit van eindgebruikers wordt gehandhaafd binnen verschillende interactietypen, waaronder A2A-protocollen, MCP-toolaanroepen en REST-API-verzoeken. Door identiteitsbeheer op de Omni Gateway-laag te centraliseren via uitgaande authenticatiebeleidsvormen kunnen ondernemingen hun gehele agentennetwerk beveiligen zonder back-endservices of agenten te wijzigen. Zie Trusted Agent Identity voor de Agentic Enterprise voor meer informatie.

3. RAG-beveiliging in Data 360

Data 360 ondersteunt op kenmerken gebaseerde toegangscontrole (ABAC, attribute-based access control) op object-, veld- en rijniveau via instellingen voor Gegevensbeheerbeleid. Dit is de primaire manier om te bepalen welke gegevens zichtbaar zijn voor wie, inclusief binnen RAG-zoekindexen. Voor gestructureerde gegevens worden toegangsvoorwaarden voor gebruikers geïmplementeerd met behulp van gebruikerskenmerken en machtigingensets. Voor ongestructureerde gegevens kan filteren van metagegevens (vooraf filteren op zoekindexen) beperken wat wordt opgehaald.

Communicatie met de LLM verloopt via de Einstein Trust Layer, die vertrouwelijke/PII-informatie maskeert voordat deze het model bereikt dat de privacy van gegevens beschermt, niet alleen tijdens zoeken, maar ook voordat deze wordt gegenereerd.

Zorg er ter bescherming tegen RAG-vergiftiging voor dat er strikte regels voor gegevensbeheer en validatie worden toegepast voordat gegevens beschikbaar komen voor vectorzoekopdrachten. De Einstein Trust Layer kan ook prompt masking/toxiciteitscontroles afdwingen. U kunt strenge machtigingensets toepassen op het profiel Agentgebruiker.

4. Nieuw benoemd gegevenmodel Salesforce heeft de authenticatiearchitectuur vernieuwd door een model met benoemde gegevens op twee niveaus te introduceren dat zorgen tussen connectiviteit en identiteit duidelijk scheidt. Gebruik dit wanneer u aanroepen doet via Apex en vermijd het maken van uw eigen authenticatieprotocol. Dit model biedt ook uitbreidbaarheid en verbeterde beveiliging. Externe inloggegevens bevinden zich aan de basis van dit model. Ze slaan de feitelijke authenticatiedetails op en ondersteunen een rijke set protocollen, waaronder OAuth 2.0 Client Credentials, JWT Bearer en AWS Signature V4, terwijl ze ook definiëren hoe principals worden toegewezen: als één benoemde principal (gedeeld tussen alle gebruikers) of als principals per gebruiker (waarbij elke gebruiker authenticeert met zijn of haar eigen identiteit). Benoemde gegevens fungeren op hun beurt als de eindpuntlaag. Ze definiëren de aanroep-URL en verwijzen naar een extern inloggegeven om de authenticatiehanddruk af te handelen, waardoor de eindpuntconfiguratie netjes wordt ontkoppeld van inloggegevensbeheer. Om authenticatiestromen per gebruiker in te schakelen, wijzen beheerders machtigingensets toe aan de juiste principal voor externe inloggegevens, zodat alleen gebruikers met de juiste toewijzing van machtigingensets aanroepen kunnen aanroepen onder hun eigen identiteit. Dit ontwerp met twee lagen vereenvoudigt niet alleen de veilige configuratie van aanroepen, maar geeft architecten ook veel meer flexibiliteit en controle over de manier waarop integraties worden geverifieerd binnen via Salesforce verbonden systemen. Zie de documentatie Benoemde inloggegevens voor meer informatie.

Deze sectie wijst de gegevensverwerkingspatronen van de architectuur toe aan de nalevingsverplichtingen die het meest voorkomen in gereguleerde implementaties voor ondernemingen.

Toegangscontrole: Het integratiegebruikersmodel met de minste rechten dat wordt beschreven in de integratiepatronen (Benoemde inloggegevens met bereik, OAuth 2.0-bereiken per agent, goedgekeurde gatewaylijsten) wordt rechtstreeks toegewezen aan logische toegangsbesturingselementen. Bewaar bewijs dat het bereik van de inloggegevens van elke agent is beoordeeld en goedgekeurd.

Auditlogboekregistratie: Vereisten voor het vastleggen van audits per patroon (sessie-ID, toolaanroepen, invoerparameters die zijn opgeschoond van gevoelige waarden, uitkomsten) voldoen aan de besturingselementen voor bewaking en vastleggen. Zorg ervoor dat logboeken manipuleerbaar zijn, gedurende de vereiste periode worden bewaard en toegankelijk zijn voor het beveiligingsteam zonder toegang tot productiesystemen.

Wijzigingsbeheer: Schemawijzigingen van MCP-tools en kaartupdates van A2A-agenten die van invloed zijn op consumenten, vormen interfacewijzigingen en moeten worden onderworpen aan besturingselementen voor wijzigingsbeheer. Versietools expliciet (vermeld in inkomend patroon van MCP) en behandelen brekende wijzigingen als configuratie-events die goedkeuring vereisen.

Beschikbaarheid: Gelijktijdige agentlimieten, limieten voor opnieuw proberen voor door events geactiveerde patronen en “dead-letter”-routering voor mislukte events vormen beschikbaarheidscontroles. Documenteer de verwachte doorvoerenvelop en de foutwerking voor elk geïmplementeerd patroon als onderdeel van het pakket met bewijs van beschikbaarheid.

Opmerking: Deze lijst is geen volledige handleiding voor het waarborgen van de naleving van uw agentische oplossingen. Aan alle toepasselijke wettelijke vereisten moet worden voldaan.

• Aan de slag met de Agent-API
• Vertrouwde agenten inschakelen met Data 360
• Overzicht van MuleSoft Omni Gateway
• OAuth 2.0 On-Behalf-Of Injectiebeleid voor inloggegevens
• Trusted Agent Identity voor de Agentic Enterprise

Gulal Kumar is een Software Engineering Architect bij Salesforce met meer dan 20 jaar ervaring. Zijn expertise omvat AI, integratie, API’s en enterprisearchitectuur, met een focus op het stimuleren van bedrijfstransformatie door middel van veilige, veerkrachtige en innovatieve AI-oplossingen. Verbind met hem via LinkedIn.