La guida all'interoperabilità di Agentforce per architetti

Autore: AgentforceTeam di prodotto (Pragya Anand , Moe Basi , Shiv Ramanna , Kyle Bransky )

Continua a leggere per saperne di più su come definire il tuo approccio all'interoperabilità.
Poi scarica la Parte 2 come guida di riferimento da utilizzare durante lo sviluppo.

Prima di progettare sistemi con più agenti, è importante capire come funziona un singolo agente. Un agente Agentforce è composto da sottoagenti (precedentemente chiamati "Argomenti"), elementi modulari destinati a domini specifici, ciascuno con azioni definite (ad esempio, Flusso, Apex, Prompt).

Ogni agente Agentforce esegue il proprio ciclo di ragionamento LLM, coordinando il modo in cui i compiti vengono delegati tra i sottoagenti e come vengono formulate le risposte fino al raggiungimento dell'obiettivo. Il motore di ragionamento di Agentforce estende questo ciclo con il determinismo basato sugli script agente, aggiungendo transizioni esplicite e sequenze tra i subagenti, garantendo un comportamento prevedibile e controllabile invece di affidarsi esclusivamente alle decisioni dell'LLM. È proprio questa combinazione tra ragionamento LLM e scripting deterministico a rendere possibili i flussi di lavoro aziendali. Un singolo agente può gestire molte cose, ma man mano che la complessità cresce, si scontra con questi ostacoli:

• Limiti dei confini dei dati: non è possibile accedere a dati, flussi di lavoro e autorizzazioni che risiedono in diverse organizzazioni o sistemi Salesforce. Si tratta di un ostacolo architettonico che una progettazione a singolo agente non può superare.
• Sovraccarico di contesto: Il contesto del motore di ragionamento LLM si riempie di istruzioni, risultati delle azioni e cronologia delle conversazioni fino a quando non inizia a ignorare le regole fondamentali o a confondere gli argomenti.
• Crollo della specializzazione di dominio: un agente che cerca di essere esperto in tutto applica la logica sbagliata per richiamare specifici sottoagenti. Più grande è il blocco di istruzioni, minore è la precisione.

Quadro decisionale: usa agenti singoli quando il tuo processo aziendale è relativamente semplice, opera all'interno di un unico dominio e richiede un insieme unificato di accesso ai dati tra i suoi sottoagenti.

L'orchestrazione SOMA (singola organizzazione, più agenti) consente a più agenti Agentforce specializzati di interoperare senza problemi all'interno di un'unica organizzazione Salesforce. Invece di costringere gli utenti a gestire singolarmente le conversazioni con diversi agenti, l'orchestrazione SOMA offre un unico punto di contatto unificato per le conversazioni. Dietro le quinte, un "superagente" o un agente "orchestratore" coordina e delega in modo intelligente i compiti agli agenti specializzati, assicurando che ogni attività venga gestita dall'agente più adatto.

Quadro decisionale: usa l'orchestrazione SOMA quando i tuoi clienti desiderano un'esperienza con punto di accesso unificato per agenti specializzati che operano all'interno di un unico ambiente (dell'organizzazione) Salesforce.

• Pro: semplifica l'esperienza utente fornendo un unico punto di accesso conversazionale per più agenti specializzati.
• Contro: limitato ai dati e ai flussi di lavoro disponibili all'interno di una singola organizzazione Salesforce.

L'orchestrazione MOMA (più organizzazioni, più agenti), come evoluzione logica del modello a singola organizzazione (SOMA), consente a più organizzazioni Salesforce di fornire un'esperienza unificata degli agenti senza la necessità di un consolidamento complesso dei dati. Questa architettura si basa su una filosofia di delega intenzionale anziché su una rete aperta e impone un vincolo intenzionale a un solo livello di profondità (Agente A>Agente B, non Agente A->B->C) per impedire concatenazioni imprevedibili. La sicurezza è garantita dall'esecuzione basata sull'identità dell'utente e dall'operatività all'interno di un confine di fiducia Data 360 One (DC1).

Quadro decisionale: usa l'orchestrazione MOMA quando la tua rete nativa Agentforce ha bisogno di delegare in modo sicuro le attività tra diverse organizzazioni Salesforce senza consolidare i modelli di dati.

• Pro: offre un'esperienza unificata per gli agenti in contesti aziendali complessi, mantenendo al contempo una rigorosa residenza dei dati.
• Contro: mappare l'identità degli utenti tra più organizzazioni e condividere il contesto tra di esse può essere complicato.

Il client Model Context Protocol (MCP) permette agli amministratori di Agentforce di registrare server MCP esterni, così chi sviluppa può integrare strumenti, risorse e azioni remote all'interno di Agentforce in modo standardizzato. Questo permette ad Agentforce di utilizzare funzionalità esterne tramite un contratto di strumento, anziché tramite integrazioni punto a punto personalizzate.

Quadro decisionale: usa il client MCP quando Agentforce deve rimanere l'orchestratore principale e ha semplicemente bisogno di accedere a funzionalità esterne come strumenti. Ad esempio, per estrarre dati da un sistema esterno, avviare un flusso di lavoro, effettuare una ricerca in una fonte di conoscenza o eseguire un'azione tramite una piattaforma di terze parti.

Usa il client MCP quando Agentforce deve utilizzare una funzionalità esterna come strumento.

• Pro: trasforma i servizi esterni in strumenti sicuri e gestibili per Agentforce, senza bisogno di codice personalizzato; include funzionalità di sicurezza come i controlli di integrità semantica (anti-rug pull) e la valutazione del rischio per prevenire l'avvelenamento degli strumenti. Mantiene il ciclo di ragionamento incentrato su Agentforce ampliando al contempo le possibilità di Agentforce.
• Contro: l'astrazione è intenzionalmente incentrata sullo strumento. Se la funzionalità remota è meglio modellata come un agente specializzato che dovrebbe gestire parte del ragionamento o del flusso di lavoro, forzarla nell'MCP può risultare innaturale. Inoltre, poiché lo schema è definito dal server esterno, le modifiche al contratto possono causare il fallimento dell'integrazione fino all'aggiornamento o alla nuova registrazione.

A2A Agentforce in uscita è il modo nativo che permette agli agenti di Agentforce di collaborare direttamente con un agente di terze parti. Per abilitarlo, gli amministratori devono prima registrare l'agente esterno specificandone le competenze, le capacità e i protocolli di trasporto. Una volta registrato e connesso a un agente Agentforce, diventa disponibile in fase di esecuzione per una delega sicura delle attività su più piattaforme.

Quadro decisionale: usa A2A Agentforce quando la tua rete Agentforce nativa deve interagire in modo sicuro con agenti di fornitori esterni, come Google o Box. Nota: in questo caso, un agente deve delegare il lavoro a un altro agente che si occupa di parte del ragionamento, della pianificazione o dell'esecuzione.

• Pro: poiché è integrato direttamente in Agentforce, non richiede di acquistare strumenti di orchestrazione esterni per gestire questi flussi di lavoro multi-agente. Offre agli utenti un ecosistema di AI "a marchio unificato" e sfrutta le competenze predefinite delle piattaforme esterne.
• Contro: fidarsi di agenti di terze parti e garantire la privacy dei dati tra i vari sistemi può rappresentare una sfida. Richiede la registrazione manuale delle funzionalità dell'agente di terze parti e l'allineamento agli standard di autenticazione.

Utilizza questa semplice regola: la differenza fondamentale non sta nel fatto che l'AI sia presente o meno da entrambe le parti. La differenza fondamentale sta nel modo in cui viene modellata la funzionalità remota:

• Se è modellata come uno strumento, usa MCP
• Se è modellata come un agente collaborativo, usa A2A

A2A in entrata permette agli agenti esterni di terze parti di attingere in modo nativo alle competenze e ai dati specializzati di un agente Agentforce. Questa configurazione considera Agentforce come un "esperto" di grande valore che può essere chiamato dai sistemi esterni per eseguire azioni specifiche di Salesforce. Esponendo le funzionalità di Agentforce tramite un endpoint API sicuro, le piattaforme esterne possono delegare attività a Salesforce senza che l'utente debba mai uscire dalla propria applicazione di terze parti.

Quadro decisionale: usa A2A in entrata quando la tua interfaccia AI principale risiede in un sistema di terze parti (come un portale personalizzato o un bot esterno) ma deve eseguire flussi di lavoro complessi all'interno di Salesforce.

• Pro: fornisce alle applicazioni esterne dati Salesforce in tempo reale e automazione senza duplicare la logica.
• Contro: richiede che il sistema esterno gestisca l'orchestrazione e la logica di "passaggio di consegne" per garantire un'esperienza utente fluida.

Il server MCP ospitato da Salesforce permette di rendere disponibili le funzionalità Agentforce a host esterni, come agenti di terze parti, copiloti e piattaforme LLM, attraverso un'interfaccia MCP standardizzata. Questo permette alle piattaforme esterne di richiamare Agentforce come fornitore di strumenti, mentre Agentforce continua a incapsulare dietro le quinte le azioni aziendali, la logica di business e l'orchestrazione per attività complesse e specializzate.

Quadro decisionale: usa gli agenti Agentforce come server MCP quando una piattaforma esterna deve utilizzare Agentforce come fornitore di strumenti. Questo è particolarmente utile in due scenari:

• Interoperabilità degli agenti aziendali: quando un agente aziendale di terze parti, come Microsoft Copilot, deve richiamare un agente Agentforce perché Agentforce contiene le azioni aziendali necessarie per completare l'attività.
• Distribuzione tramite LLM/canali esterni: quando vuoi che le funzionalità di Agentforce con il tuo marchio siano accessibili all'interno di interfacce conversazionali esterne come ChatGPT, Gemini o host simili.

In questo modello, la piattaforma esterna rimane l'esperienza principale per l'utente, mentre Agentforce viene intenzionalmente esposto tramite MCP come endpoint dello strumento. Anche se Agentforce è di tipo agentico a livello interno, il modello di interoperabilità rimane comunque MCP perché la relazione esterna consiste nell'invocazione dello strumento piuttosto che nella delega tra agenti alla pari.

• Pro: semplifica l'utilizzo di agenti Agentforce potenti e specializzati, creati per la tua azienda sulla base dei dati di Salesforce (fatturazione, assistenza, ecc.) e riutilizzabili al di fuori di Salesforce tramite un protocollo standardizzato; permette agli assistenti esterni e agli agenti aziendali di utilizzare l'orchestrazione e le azioni aziendali di Agentforce senza doverle ricostruire; supporta sia l'interoperabilità aziendale che la distribuzione tramite canali esterni.
• Contro: L'host esterno gestisce l'esperienza utente primaria e il ciclo di ragionamento, quindi Agentforce ha meno controllo su come e quando viene chiamato. Gli scenari aziendali richiedono inoltre una gestione rigorosa per l'autenticazione, l'autorizzazione, la propagazione dell'identità e il passaggio del contesto.

La panoramica delineata sopra è solo l'inizio, e ti aiuta a identificare quale modello di orchestrazione si adatta al tuo caso d'uso. Continua a leggere per scoprire come progettarlo e implementarlo.

Ecco cosa imparerai scaricando la Parte 2: La guida di riferimento per l'orchestrazione di più agenti per architetti:

• scomponi i processi complessi in agenti che mantengono la responsabilità delle proprie azioni. Tre strategie, in base alla competenza di dominio, alla fase del flusso di lavoro o alla capacità, trasformano un unico agente sovraccarico in un gruppo di specialisti, ognuno dei quali svolge bene un unico compito.
• Abbina la tua architettura a uno dei cinque modelli di orchestrazione. La modalità supervisionata e la modalità di passaggio di consegne sono già disponibili oggi. L'esecuzione parallela, gli agenti in background guidati dagli eventi e i modelli "Plan and Present" sono in programma.
• Scegli tra il routing guidato da LLM e quello deterministico. Il motore di ragionamento si adatta alle richieste aperte. Lo script agente ti offre un controllo deterministico quando un flusso di lavoro richiede una sequenza garantita. La maggior parte dei progetti multi-agente utilizza entrambi.
• Evita i sette anti-pattern più comuni. L'orchestrazione a maglia, i subagenti sovrapposti e troppi livelli di delega sono i modi più rapidi per minare la governance e l'osservabilità su larga scala.
• Progetta in base a ciò che è supportato oggi. I vincoli attuali dello script agente (handoff permanente, delega annidata, limite di sette subagenti collegati) determinano quali modelli puoi implementare subito e quali invece devi pianificare per il prossimo trimestre.