Arkitektens guide till Agentforce-interoperabilitet

Författare: Agentforce-produktteamet (Pragya Anand , Moe Basi , Shiv Ramanna , Kyle Bransky )

Läs vidare för att lära dig mer om hur du definierar din strategi för interoperabilitet.
Ladda sedan ned del 2 som referensguide medan du bygger.

Innan man utformar system med flera agenter är det viktigt att förstå hur en enskild agent fungerar. En Agentforce-agent består av underagenter (kallades tidigare ämnen), modulära byggstenar begränsade till specifika domäner, var och en med definierade åtgärder (t.ex. flöde, Apex, promptar).

Varje Agentforce-agent kör sin egen LLM-resonemangsloop och orkestrerar hur uppgifter delegeras mellan underagenter och hur svar bildas tills målet är uppnått. Agentforces resonemangsmotor utökar loopen med agentskriptbaseraddeterminism och lägger till explicita övergångar och sekvensering mellan underagenter, vilket säkerställer ett förutsägbart och kontrollerbart beteende som inte enbart förlitar sig på LLM-beslut. Denna kombination av LLM-resonemang och deterministiska skript är det som möjliggör affärsarbetsflöden. En enda agent kan hantera mycket, men i takt med att komplexiteten ökar uppstår begränsningar:

• Datagränser: Data, arbetsflöden och behörigheter som finns i olika Salesforce-organisationer eller system går inte att nå. Det är en arkitektonisk vägg som inte går att passera i en utformning med en enda agent.
• Kontextöverbelastning: Resonemangsmotorn i LLM:er fylls med instruktioner, åtgärdsresultat och konversationshistorik tills den börjar ignorera grundläggande regler eller blanda ihop ämnen.
• Kollaps av domänspecialisering: En agent som försöker vara expert på allt tillämpar fel logik för att anropa specifika underagenter. Ju större instruktionsblock, desto sämre precision.

Beslutsramverk: Använd enskilda agenter när affärsprocessen är relativt enkel, drivs inom en enda domän och kräver en enhetlig uppsättning dataåtkomst för alla sina underagenter.

SOMA-orkestrering (Single-Org, Multi-Agent) gör det möjligt för flera specialiserade Agentforce-agenter att arbeta tillsammans inom en enda Salesforce-organisation. Istället för att tvinga användare att hantera konversationer med olika agenter individuellt, tillhandahåller SOMA en enhetlig konversationsbaserad agent. Bakom kulisserna koordinerar och delegerar en ”superagent” eller ”orkestrerare” uppgifter intelligent till specialiserade agenter, vilket säkerställer att varje uppgift hanteras av den agent som är bäst rustad för den.

Beslutsramverk: Använd SOMA när dina kunder vill ha en enhetlig ”huvuddörr” för specialiserade agenter som arbetar i en enda Salesforce-organisationsmiljö.

• Fördelar: Förenklar användarupplevelsen genom att tillhandahålla en konversationsstartpunkt för flera specialiserade agenter.
• Nackdelar: Begränsat till de data och arbetsflöden som är tillgängliga inom en enda Salesforce-organisation.

MOMA-orkestrering (Multi-Org Multi-Agent), som den logiska utvecklingen av SOMA-modellen (med en organisation), gör det möjligt för flera Salesforce-organisationer att tillhandahålla en enhetlig agentupplevelse utan behov av komplex datakonsolidering. Denna arkitektur bygger på en filosofi om avsiktlig delegering istället för ett öppet nätverk och upprätthåller en avsiktlig djup begränsning på samma nivå (agent A>Agent B, inte agent A->B->C) för att förhindra oförutsägbar kedjning. Säkerheten upprätthålls genom användaridentitetsmedveten körning och drift inom en Data 360 One (DC1)-tillitsgräns.

Beslutsramverk: Använd MOMA när ditt inbyggda Agentforce-nätverk behöver delegera uppgifter på ett säkert sätt mellan olika Salesforce-organisationer utan att konsolidera datamodeller.

• Fördelar: Ger en enhetlig agentupplevelse i komplexa företagslandskap samtidigt som strikt datahemvist bibehålls.
• Nackdelar: Det kan vara utmanande att kartlägga användaridentitet inom flera organisationer och dela kontext mellan organisationer.

Modellkontextprotokoll (MCP) gör det möjligt för Agentforce-administratörer att registrera externa MCP-servrar för att integrera fjärrverktyg, resurser och åtgärder inuti Agentforce på ett standardiserat sätt. Det gör det möjligt för Agentforce att använda externa funktioner genom ett verktygsavtal snarare än genom skräddarsydda punkt-till-punkt-integrationer.

Beslutsramverk: Använd MCP-klienten när Agentforce ska förbli den primära orkestreraren och bara behöver tillgång till externa funktioner som verktyg. Till exempel att hämta data från ett externt system, anropa ett arbetsflöde, söka i en kunskapskälla eller vidta åtgärder via en tredjepartsplattform.

Använd MCP-klienten när Agentforce ska använda en extern kapacitet som ett verktyg.

• Fördelar: Omvandlar externa tjänster till säkra, styrningsbara verktyg för Agentforce utan anpassad kod. Innehåller säkerhetsfunktioner som semantiska integritetskontroller (anti-rug pull) och riskgradering för att förhindra verktygsförgiftning. Det håller resonemangsloopen centralt placerad i Agentforce samtidigt som det utökar vad Agentforce kan göra.
• Nackdelar: Abstraktionen är avsiktligt verktygscentrerad. Om fjärrkapaciteten bättre modelleras som en specialistagent som ska äga en del av resonemanget eller arbetsflödet, kan det vara bra att inte tvinga den till MCP. Eftersom schemat definieras av den externa servern kan avtalsändringar leda till att integreringen misslyckas tills den uppdateras eller registreras på nytt.

Agentforce Utgående A2A är det inbyggda sättet för Agentforce-agenter att samarbeta direkt med en tredjepartsagent. För att aktivera detta måste administratörerna först registrera den externa agenten genom att specificera dess specifika färdigheter, funktioner och transportprotokoll. När den är registrerad och ansluten till en Agentforce-agent blir den tillgänglig för säker uppgiftsdelegering över flera plattformar.

Beslutsramverk: Använd Agentforce A2A när ditt inbyggda Agentforce-nätverk behöver interagera säkert med externa leverantörsagenter, till exempel Google eller Box. Obs! Här behöver en agent delegera arbete till en annan agent som äger en del av resonemanget, planeringen eller utförandet.

• Fördelar: Eftersom det är inbyggt direkt i Agentforcebehöver du inte köpa externa orkestreringsverktyg för att hantera dessa arbetsflöden för flera agenter. Det möjliggör ett AI-ekosystem med ett ”enhetligt varumärke” för användarna och använder sig av färdig expertis från externa plattformar.
• Nackdelar: Det kan vara utmanande att lita på tredjepartsagenter och säkerställa datasekretess i olika system. Det kräver manuell registrering av tredjepartsagentens kapacitet och matchande autentiseringsstandarder.

Använd den här enkla regeln: Den viktigaste skillnaden är inte om AI finns på båda sidor. Den viktigaste skillnaden är hur fjärrkapaciteten modelleras:

• Om den modelleras som ett verktyg, använd MCP
• Om den modelleras som en samarbetsagent, använd A2A

Ingående A2A gör det möjligt för externa tredjepartsagenter att direkt anropa en Agentforce-agents specialiserade färdigheter och data. Denna inställning behandlar Agentforce som en värdefull ”expert” som kan tillkallas av externa system för att utföra Salesforce-specifika åtgärder. Genom att exponera Agentforce-funktioner via en säker API-slutpunkt kan externa plattformar delegera uppgifter till Salesforce utan att användaren någonsin lämnar sin tredjepartsapplikation.

Beslutsramverk: Använd ingående A2A när ditt primära AI-gränssnitt finns i ett tredjepartssystem (som en anpassad portal eller en extern bot) men behöver utföra komplexa arbetsflöden i Salesforce.

• Fördelar: Driver externa applikationer med Salesforce-data och automatisering i realtid utan att duplicera logik.
• Nackdelar: Kräver att det externa systemet hanterar orkestrering och överlämningslogik för att säkerställa en smidig användarupplevelse.

Salesforces värdbaserade MCP-server gör det möjligt att exponera Agentforce-kapacitet för externa värdar, till exempel tredjepartsagenter, medpiloter och LLM-plattformar, via ett standardiserat MCP-gränssnitt. Det gör att externa plattformar kan anropa Agentforce som verktygsleverantör samtidigt som Agentforce fortsätter att kapsla in företagsåtgärder, affärslogik och orkestrering bakom kulisserna för komplexa och specialiserade uppgifter.

Beslutsramverk: Använd Agentforce-agenter som en MCP-server när en extern plattform bör använda Agentforce som verktygsleverantör. Det här är särskilt användbart i två scenarier:

• Företagsagentens interoperabilitet: När en tredjeparts företagsagent, till exempel Microsoft Copilot, behöver anropa en Agentforce-agent eftersom Agentforce innehåller de företagsåtgärder som behövs för att slutföra uppgiften.
• Extern LLM/kanaldistribution: När du vill att Agentforces specifika kapacitet ska vara tillgänglig inuti externa konversationsytor som ChatGPT, Gemini eller liknande värdar.

I den här modellen förblir den externa plattformen den primära värdupplevelsen, medan Agentforce avsiktligt exponeras genom MCP som en verktygsslutpunkt. Även om Agentforce är agentiskt internt är interoperabilitetsmönstret fortfarande MCP eftersom den externa relationen är verktygsanrop snarare än delegering mellan agenter.

• Fördelar: Gör det enkelt att använda kraftfulla och specialiserade Agentforce-agenter byggda för ditt företag baserat på Salesforce-data (fakturering, support osv.) som kan återanvändas utanför Salesforce via ett standardiserat protokoll. Gör det möjligt för externa assistenter och företagsagenter att använda Agentforces orkestrering och affärsåtgärder utan att bygga om dem. Stöder både företagskompabilitet och extern kanaldistribution.
• Nackdelar: Den externa värden äger den primära användarupplevelsen och resonemangsloopen, så Agentforce har mindre kontroll över hur och när det anropas. Företagsscenarier kräver också kraftfull hantering för autentisering, auktorisering, identitetsspridning och kontextöverföring.

Översikten ovan är bara början och hjälper dig att identifiera vilket orkestreringsmönster som passar ditt användningsfall. Fortsätt läsa för att se hur du ska utforma och driftsätta det.

Det här får du lära dig i del 2: Referensguide för arkitekter om fleragentsorkestrering:

• Dela upp komplexa processer i agenter som förblir ansvariga. Tre strategier – per domänexpertis, per arbetsflödessteg eller per kapacitet – förvandlar en uppsvälld agent till en uppsättning specialister som alla är bra på en sak.
• Matcha din arkitektur med ett av fem orkestreringsmönster. Övervakat läge och Överlämningsläge är allmänt tillgängliga idag. Parallell körning, Händelsedrivna bakgrundsagenter och Planera och presentera är på gång.
• Välj mellan LLM-driven och deterministisk routing. Resonemangsmotorn anpassar sig till öppna förfrågningar. Agentskript ger dig deterministisk kontroll när ett arbetsflöde behöver en garanterad sekvens. I de flesta utformningar med flera agenter används båda.
• Undvik de sju vanligaste anti-mönstren. Mesh-orkestrering, överlappande underagenter och för många delegeringslager är de snabbaste sätten att urholka styrning och observerbarhet i stor skala.
• Utforma för det som stöds idag. Agentskriptens nuvarande begränsningar (trög överlämning, vidaredelegering, gränsen med sju anslutna underagenter) formar vilka mönster du kan skicka nu och vilka du ska planera för nästa kvartal.