Het e-book over Agentforce interoperabiliteit voor architecten

Geschreven door: Het Agentforce Productteam (Pragya Anand , Moe Basi , Shiv Ramanna , Kyle Bransky )

Lees verder voor meer informatie over het definiëren van je aanpak van interoperabiliteit.
Download vervolgens Deel 2 als naslagwerk tijdens het bouwen.

Voordat je systemen met meerdere agents ontwerpt, is het belangrijk om te begrijpen hoe één agent werkt. Een Agentforce agent bestaat uit subagents (voorheen onderwerpen genoemd), modulaire bouwstenen die zijn afgestemd op specifieke domeinen, elk met gedefinieerde acties (bijv. Stroom, Apex, Taakaanwijzingen).

Elke Agentforce agent voert zijn eigen LLM-redeneringslus uit, waarbij wordt georkestreerd hoe taken worden gedelegeerd aan subagents en hoe antwoorden worden gevormd totdat het doel is bereikt. De Agentforce redeneringsengine breidt deze lus uit met op Agentenscript gebaseerd determinisme, waarbij expliciete overgangen en volgordebepaling tussen subagents worden toegevoegd. Hierdoor wordt voorspelbaar en controleerbaar gedrag gegarandeerd in plaats van alleen te vertrouwen op LLM-beslissingen. Deze combinatie van LLM-redenering en deterministische scripts maakt bedrijfsworkflows mogelijk. Een enkele agent kan veel aan, maar naarmate de complexiteit toeneemt, loop je tegen deze muren op:

• Grenzen van data: Data, workflows en machtigingen die zich in verschillende Salesforce-organisaties of -systemen bevinden, zijn niet toegankelijk. Dit is een muur als gevolg van de architectuurwaar één agent ontwerp niet doorheen kan breken.
• Overvloed aan context: De context van de LLM-redeneringsengine wordt gevuld met instructies, actie-outputs en gespreksgeschiedenis totdat deze kernregels negeert of onderwerpen met elkaar verwart.
• Instorting van domeinspecialisatie: Een agent die in alles een expert probeert te zijn, past de verkeerde logica toe om specifieke subagents aan te roepen. Hoe groter het instructieblok, hoe onnauwkeuriger.

Beslissingskader: Gebruik enkele agents wanneer je bedrijfsproces relatief eenvoudig is, binnen één domein werkt en een uniforme set datatoegang voor alle subagents vereist.

Met de doeltreffende combinatie voor meerdere agenten in één organisatie (SOMA) kunnen meerdere gespecialiseerde Agentforce-agents naadloos samenwerken binnen één Salesforce-organisatie. In plaats van gebruikers te dwingen om gesprekken met verschillende agents afzonderlijk te beheren, biedt SOMA één uniforme gespreksagent aan de voordeur. Achter de schermen coördineert en delegeert een 'superagent' of 'arrangeur'-agent taken op slimme wijze aan gespecialiseerde agents, zodat elke taak wordt afgehandeld door de agent die er het best voor is uitgerust.

Beslissingskader: Gebruik SOMA wanneer je klanten een uniforme 'voordeur'-ervaring willen voor gespecialiseerde agents die binnen een omgeving met één Salesforce (organisatie) werken.

• Voordelen: Vereenvoudigt de gebruikerservaring door één toegangspunt voor gesprekken te bieden voor meerdere gespecialiseerde agents.
• Nadelen: Beperkt tot de data en workflows die beschikbaar zijn binnen één Salesforce-organisatie.

De doeltreffende combinatie voor meerdere agenten in meerdere organisaties (MOMA) als de logische evolutie van het SOMA-model (één organisatie), stelt meerdere Salesforce-organisaties in staat om een uniforme agentervaring te bieden zonder dat complexe dataconsolidatie nodig is. Deze architectuur is gebouwd op een filosofie van bewuste delegatie in plaats van een open netwerk en dwingt een opzettelijke diepe beperking van één niveau af (Agent A>Agent B, niet Agent A->B->C) om onvoorspelbare koppeling te voorkomen. De beveiliging wordt gehandhaafd door uitvoering met bewuste gebruikersidentiteit en door actief binnen een Data 360 One (DC1)-vertrouwensgrens te werken.

Beslissingskader: Gebruik MOMA wanneer je native Agentforce netwerk taken veilig moet delegeren aan verschillende Salesforce-organisaties zonder datamodellen te consolideren.

• Voordelen: Biedt een uniforme agentervaring in complexe bedrijfsomgevingen met behoud van strikte dataopslag.
• Nadelen: Het toewijzen van gebruikersidentiteiten aan meerdere organisaties en het delen van context tussen organisaties kan een uitdaging vormen.

Met de Model Context Protocol (MCP)-client kunnen Agentforce-beheerders externe MCP-servers registreren, zodat builders externe tools, resources en acties binnen Agentforce op een gestandaardiseerde manier kunnen integreren. Dit maakt het mogelijk voor Agentforce om externe mogelijkheden te gebruiken via een toolcontract in plaats van via op maat gemaakte punt-voor-punt-integraties.

Beslissingskader: Gebruik de MCP-client wanneer Agentforce de primaire arrangeur moet blijven en alleen toegang nodig heeft tot externe mogelijkheden als tools. Denk aan het ophalen van data uit een extern systeem, het aanroepen van een workflow, het doorzoeken van een kennisbron of het ondernemen van actie via een platform van derden.

Gebruik de MCP-client wanneer Agentforce een externe mogelijkheid als tool moet gebruiken.

• Voordelen: Zet externe services om in veilige, beheersbare tools voor Agentforce zonder aangepaste code; bevat veiligheidsfuncties zoals semantische integriteitscontroles (anti-oplichting) en risicoscores om vergiftiging van tools te voorkomen. Het houdt de redeneringlus centraal in Agentforce en breidt uit wat Agentforce kan.
• Nadelen: De abstractie is bewust toolgericht. Als de externe mogelijkheid beter is gemodelleerd als een gespecialiseerde agent die een deel van de redenering of workflow moet bezitten, kan het onnatuurlijk zijn om deze in MCP te forceren. Omdat het schema wordt gedefinieerd door de externe server, kunnen contractwijzigingen er ook voor zorgen dat de integratie mislukt totdat deze wordt vernieuwd of opnieuw wordt geregistreerd.

Agentforce Uitgaande A2A is de native manier voor Agentforce-agents om rechtstreeks samen te werken met een externe agent. Om dit mogelijk te maken, moeten beheerders eerst de externe agent registreren door de specifieke vaardigheden, mogelijkheden en transportprotocollen te specificeren. Eenmaal geregistreerd en verbonden met een Agentforce-agent, wordt deze tijdens run-time beschikbaar voor veilige taakoverdracht tussen platformen.

Beslissingskader: Gebruik Agentforce A2A wanneer je native Agentforce netwerk veilig moet communiceren met agents van externe leveranciers, zoals Google of Box. Opmerking: Hier moet de ene agent werk delegeren aan een andere agent die eigenaar is van een deel van de redenering, planning of uitvoering.

• Voordelen: Omdat het rechtstreeks is ingebouwd in Agentforce, hoef je geen externe orkestratietools aan te schaffen om deze workflows met meerdere agents te beheren. Het maakt een AI-ecosysteem van een 'uniform merk' mogelijk voor gebruikers en het maakt gebruik van kant-en-klare expertise van externe platforms.
• Nadelen: Het vertrouwen van externe agents en het waarborgen van dataprivacy in verschillende systemen kan een uitdaging zijn. Het vereist handmatige registratie van de mogelijkheden van de externe agent en overeenkomende authenticatiestandaarden.

Gebruik deze eenvoudige regel: Het belangrijkste onderscheid is niet of AI aan beide kanten bestaat. Het belangrijkste onderscheid is hoe de externe mogelijkheid wordt gemodelleerd

• Als deze is gemodelleerd als tool, gebruik dan MCP
• Als deze is gemodelleerd als samenwerkende agent, gebruik dan A2A

Met Inkomende A2A kunnen externe agents native een beroep doen op de gespecialiseerde vaardigheden en data van een Agentforce-agent. Deze set-up behandelt Agentforce als hoogwaardige 'expert' die door externe systemen kan worden opgeroepen om Salesforce-specifieke acties uit te voeren. Door Agentforce-mogelijkheden via een veilig API-endpoint beschikbaar te stellen, kunnen externe platforms taken delegeren aan Salesforce zonder dat de gebruiker ooit zijn applicatie van derden hoeft te verlaten.

Beslissingskader: Gebruik Inkomende A2A wanneer je primaire AI-interface zich in een systeem van derden bevindt (zoals een aangepaste portal of externe bot), maar complexe workflows moet uitvoeren binnen Salesforce.

• Voordelen: Voorziet externe applicaties van realtime Salesforce-data en automatisering zonder logica te dupliceren.
• Nadelen: Vereist dat het externe systeem de orkestratie- en overdrachtslogica afhandelt om een soepele gebruikerservaring te garanderen.

Met de gehoste MCP-server van Salesforce kunnen Agentforce-mogelijkheden worden blootgesteld aan externe hosts, zoals externe agents, copilots en LLM-platformen via een gestandaardiseerde MCP-interface. Hierdoor kunnen externe platformen Agentforce aanroepen als aanbieder van tools, terwijl Agentforce bedrijfsacties, bedrijfslogica en orkestratie achter de schermen blijft inbouwen voor complexe en gespecialiseerde taken.

Beslissingskader: Gebruik Agentforce-agents als MCP-server wanneer een extern platform Agentforce moet gebruiken als aanbieder van tools. Dit is vooral nuttig in twee scenario's:

• Interoperabiliteit van bedrijfsagents: Wanneer een externe bedrijfsagent, zoals Microsoft Copilot, een Agentforce-agent moet aanroepen omdat Agentforce de bedrijfsacties bevat die nodig zijn om de taak te voltooien.
• Externe LLM/kanaaldistributie: Wanneer je wilt dat merkgebonden Agentforce-mogelijkheden toegankelijk zijn binnen externe gespreksomgevingen zoals ChatGPT, Gemini of vergelijkbare hosts.

In dit model blijft het externe platform de primaire hostervaring, terwijl Agentforce doelbewust wordt blootgesteld via MCP als een endpoint van de tool. Zelfs als Agentforce intern agentisch is, blijft het interoperabiliteitspatroon nog steeds MCP, omdat de externe relatie de aanroeping van de tool is in plaats van peer-agent-delegatie.

• Voordelen: Maakt het makkelijk om krachtige en gespecialiseerde Agentforce-agents te gebruiken die voor je bedrijf zijn gebouwd op basis van Salesforce-data (facturering, support, enz.) die buiten Salesforce kunnen worden hergebruikt via een gestandaardiseerd protocol; stelt externe assistenten en bedrijfsagents in staat om de orkestratie en bedrijfsacties van Agentforce te gebruiken zonder ze opnieuw op te bouwen; ondersteunt zowel de interoperabiliteit van het bedrijf als de distributie van externe kanalen.
• Nadelen: De externe host is eigenaar van de primaire gebruikerservaring en redeneringslus, waardoor Agentforce minder controle heeft over hoe en wanneer deze wordt aangeroepen. Bedrijfsscenario's vereisen ook een sterke afhandeling voor authenticatie, autorisatie, identiteitsverspreiding en het doorgeven van context.

Het bovenstaande overzicht is nog maar de aanzet, zodat je kunt bepalen welk orkestratiepatroon past bij je use case. Lees verder om te zien hoe je deze kunt ontwerpen en verzenden.

Dit is wat je leert wanneer je Deel 2 downloadt: Het naslagwerk voor architecten voor doeltreffende combinatie voor meerdere agenten:

• Verdeel complexe processen in agents die toerekenbaar blijven. Drie strategieën – per domeinexpertise, per workflowfase of per mogelijkheid – maken van één omvangrijke agent een set specialisten die elk één taak goed uitvoeren.
• Koppel je architectuur aan een van de vijf orkestratiepatronen. De begeleide modus en de overdrachtsmodus zijn tegenwoordig algemeen beschikbaar. Parallelle uitvoering, event-driven agents op de achtergrond en plannen en presenteren staan op de routekaart.
• Kies tussen LLM-gestuurde en deterministische routering. De redeneringsengine buigt zich naar open verzoeken. Agentenscript geeft je deterministische controle wanneer een workflow een gegarandeerde volgordebepaling nodig heeft. De meeste ontwerpen met meerdere agents gebruiken ze allebei.
• Vermijd de zeven meest voorkomende anti-patronen. Rommelige orkestratie, overlappende subagents en te veel delegatielagen zijn de snelste manieren om governance en observeerbaarheid op schaal te eroderen.
• Ontwerp voor wat er vandaag wordt ondersteund. De huidige beperkingen van agentenscript (overdracht die blijft hangen, geneste delegatie, de limiet van zeven verbonden subagents) geven vorm aan welke patronen je nu kunt verzenden versus welk patroon je voor het volgende kwartaal moet plannen.