Nel panorama multiagente in evoluzione, gli agenti sono più efficaci quando vengono assegnate operazioni specifiche e dettagliate. Ciò richiede una rete diversificata di agenti specializzati riutilizzabili. La sfida principale, tuttavia, è coordinare questi numerosi ed eterogenei agenti, che possono provenire da fonti diverse, per collaborare efficacemente verso obiettivi aziendali comuni. Senza una piattaforma unificata, questa complessità porta a una proliferazione degli agenti e a una grave mancanza di governance.

Questi agenti AI si moltiplicano rapidamente, incorporati in piattaforme SaaS, sviluppati internamente o inseriti in pacchetti con i più diffusi LLM. Questa moltiplicazione risulta in silos organizzativi disconnessi. Sebbene ottimizzi le operazioni all'interno delle sue applicazioni native, un agente spesso non ha una visione aziendale olistica. Questa mancanza di visibilità impedisce agli agenti di orchestrare, proteggere e governare efficacemente le azioni in domini e sistemi diversi.

MuleSoft Agent Fabric affronta la sfida di gestire la "diffusione degli agenti" e consentire l'orchestrazione senza interruzioni di agenti diversi, indipendentemente dalla loro origine. Stabilisce le procedure consigliate per l'architettura e fornisce gli strumenti necessari per creare la rete degli agenti. Una rete di agenti si riferisce a una raccolta coordinata di agenti, strumenti e risorse AI che lavorano insieme per eseguire processi aziendali complessi in più fasi.

MuleSoft Agent Fabric è una piattaforma unificata che offre a ogni azienda un modo semplice per scoprire, orchestrare, governare e osservare qualsiasi agente indipendentemente da dove viene creato.

Scopri: Registro agenti offre un catalogo centralizzato di tutti gli agenti e gli strumenti di intelligenza artificiale dell'organizzazione. Consente l'individuazione e il riutilizzo di asset interni, incorporati SaaS ed esterni. Fornendo un'unica fonte di dati per tutti gli asset agenti, Registro agenti elimina la ridondanza e garantisce che gli sviluppatori possano sfruttare le funzionalità esistenti su larga scala.

Orchestra: MuleSoft Agent Broker è una soluzione di instradamento intelligente che abbina dinamicamente le operazioni all'agente o allo strumento più adatto. Basato su un LLM a scelta, coordina gli agenti e gli strumenti per garantire che le richieste a più fasi e i processi aziendali complessi vengano eseguiti con risultati tracciabili e di elevata affidabilità.

Govern: MuleSoft Agent Governance utilizza Flex Gateway e il relativo supporto per Model Context Protocol (MCP) e Agent2Agent (A2A). Con Flex Gateway, le aziende possono applicare policy di sicurezza e conformità a ogni interazione agente-agente e agente-strumento.

Osserva: Agent Visualizer offre un'osservabilità in tempo reale attraverso una mappa dinamica e interattiva delle interazioni degli agenti. Traccia le decisioni, monitora lo stato del sistema, consentendo così un'ottimizzazione continua e una supervisione affidabile dell'intero ecosistema degli agenti.

Agent Fabric promuove un approccio YAML (specific-first) in cui gli utenti definiscono le reti degli agenti tramite un descrittore di metadati (il "file YAML"). Questo file YAML non è indipendente da MuleSoft e separa la definizione della rete agente dalla sua esecuzione.

Ogni rete di agenti (YAML) definisce un'area funzionale specifica con i relativi asset agenti, incluse le relative regole operative e policy. YAML viene utilizzato per abilitare i quattro pilastri del tessuto agente:

1. Scopri: Compilare il Registro agenti con asset agenti esistenti, ad esempio:
   1. Agenti distribuiti su varie piattaforme (MuleSoft o altre)
   2. Server MCP
   3. Provider LLM
2. Orchestra: Creazione di broker agenti per l'orchestrazione
3. Governa: Applicare policy sugli asset per la sicurezza e la governance
4. Osserva: Definire e riutilizzare le connessioni agli asset definiti. Sono inoltre disponibili funzionalità di osservabilità e monitoraggio per le reti di agenti.

Il journey utente inizia in Anypoint Code Builder. Utilizzare il nuovo comando disponibile tramite la tavolozza dei comandi denominata "MuleSoft: Creare un progetto di rete agente" per creare un nuovo progetto. Questo comando crea un nuovo progetto (la “rete degli agenti”) contenente due file.

• agent-network.yaml: Questo file definisce la configurazione per il sistema multi-agente, abilitando l'orchestrazione di agenti AI con strumenti esterni (tramite MCP) e agenti (tramite protocollo A2A). Questo formato è un modo dichiarativo per definire le funzionalità, le dipendenze e le integrazioni degli agenti.

• exchange.json: Tutti i progetti di rete degli agenti hanno anche un file exchange.json. Questo file contiene i metadati degli asset disponibili in Anypoint Exchange dopo la pubblicazione degli asset di rete degli agenti.

Lo sviluppo della rete di agenti segue un ciclo di vita di sviluppo software (SDLC) standard che prevede quattro fasi principali:

1. Impostazione ambiente: Impostazione dell'ambiente di runtime e dei gateway
2. Creazione e progettazione di progetti: Creazione della specifica del progetto Agent Network
3. Creazione e pubblicazione: Creare e pubblicare asset nel Registro agenti
4. Distribuzione: Distribuire o promuovere la rete degli agenti in un determinato ambiente

Dopo aver creato il progetto e generato l'applicazione MuleSoft e gli asset richiesti, renderli disponibili in Exchange. In Anypoint Code Builder, attivare il processo di creazione e pubblicazione utilizzando "MuleSoft: Comando Publish Agent Broker Project to Exchange” disponibile tramite tavolozza dei comandi.

La fase di pubblicazione trasforma ogni asset agente nel file YAML in una specifica A2A, MCP o LLM e lo pubblica in Exchange.

Inoltre, il sistema pubblica YAML in Exchange utilizzando un nuovo tipo di asset di rete agente. È possibile visualizzare questo asset nell'interfaccia utente del Registro agenti e cercarlo tramite l'API Exchange.

Fare riferimento a un file Agent Network che definisce una rete di agenti per un'azienda. Questa rete di agenti attiva la rete per l'evasione degli ordini in Salesforce, Stripe, un altro agente dell'evasione ordini e un server MCP dell'inventario con un'unica esperienza basata su policy.

• Scopri
  Pubblicare gli agenti e gli strumenti esistenti (ad esempio Salesforce, Stripe, Evasione ordini e Inventario) come asset Exchange da riutilizzare. Inoltre, la definizione di evasione ordine (YAML), che è disponibile in versione e condivisibile, consentendo un rapido adattamento per ruoli, regioni o società controllate senza ricreare i flussi.
• Orchestra
  Un broker agente utilizza un LLM per scomporre il processo di evasione dell'ordine in una sequenza di operazioni, ad esempio la verifica dei dettagli del cliente, l'allocazione dell'inventario e il calcolo dei costi di spedizione. Quindi esegue questo flusso di lavoro chiamando gli agenti MCP e A2A, assicurando che le approvazioni human-in-the-loop vengano richieste ogni volta che necessario.
• Governato
  Anypoint Flex Gateway impone l'autenticazione, l'accesso con privilegi minimi e i guardrail. Le policy Gestore API garantiscono controlli coerenti in tutte le chiamate e gli scambi di dati.
• Osserva
  Il monitoraggio e le tracce offrono una visibilità completa su avanzamento, errori e latenza. La visualizzazione mostra quali agenti hanno interagito e dove si sono verificati colli di bottiglia.
• Trust e conformità
  Le credenziali centralizzate, gli itinerari di controllo e l'eredità delle polizze supportano la sicurezza, la privacy e i requisiti normativi (gestione delle informazioni personali, approvazioni e separazione delle mansioni).

Il diagramma mostra i diversi nodi della rete di agenti (metadati) definiti in YAML.

• Scopo: Exchange è il catalogo per agenti, strumenti e altri asset. Il suo obiettivo principale è risolvere la "diffusione degli agenti" fornendo un unico catalogo governato per la scoperta, la cura e la gestione del ciclo di vita di agenti eterogenei. Consente agli sviluppatori di trovare e riutilizzare gli agenti, ai titolari della piattaforma di mantenere la visibilità e agli orchestratori di scoprire le funzionalità.
• Eterogeneo per progettazione: Anypoint Exchange ora supporta tre nuovi asset: agenti, MCP e LLM. Exchange è progettato per essere un catalogo universale, per registrare e gestire qualsiasi tipo di agente. Supporta agenti, server MCP e provider LLM compatibili con A2A da qualsiasi fonte, inclusi agenti MuleSoft di terze parti, Agentforce e personalizzati.
• Metadati principali: Ogni asset registrato ha un insieme di base di metadati immutabili, inclusi Nome e versione univoci, Proprietà e Publisher. Vengono tracciati anche gli stati del ciclo di vita (sviluppo, gestione temporanea, produzione, deprecato).
• Scoperta:
  • Design-Time: Gli sviluppatori possono scoprire gli agenti registrati tramite l'interfaccia utente Exchange esistente o tramite la ricerca per linguaggio naturale con Vibes nel Generatore di codici Anypoint.
• Tag e classificazione: Gli asset possono essere classificati in base al tipo (agente, MCP, LLM, broker) e al dominio (ad esempio, risorse umane, meteo) utilizzando un sistema di assegnazione di tag chiave-valore di base, abilitando policy dinamiche di collegamento, ricerca e selezione.
• Catalogo: L'archivio supporta modelli di catalogo sia privati che interni per la condivisione degli agenti all'interno di un'organizzazione.
• Visualizzazione: Fornisce uno strumento visivo per supportare le visualizzazioni rete, mostrando le connessioni per singoli asset o l'intera mappa di nodi e link in tutta l'organizzazione, con funzionalità di filtro.

I broker all'interno di una rete di agenti possono fare riferimento ad agenti registrati, server MCP e provider LLM memorizzati in Anypoint Exchange. Tuttavia, se non sono già registrati, possono essere dichiarati nei metadati di Agent Network (YAML) e vengono registrati automaticamente. Nell'esempio, più agenti, server MCP e provider LLM vengono dichiarati e registrati in Anypoint Exchange.

Un broker agente è un agente di instradamento intelligente che coordina la delega delle operazioni tra gli agenti specializzati di un'azienda. È definito dagli agenti e dai server MCP utilizzati per eseguire le operazioni.

Un broker è un agente specializzato che appare in Anypoint Exchange dopo la pubblicazione di un asset di rete agente e il riutilizzo da parte di altri broker.

I broker sono definiti nella sezione broker di YAML. I broker definiti vengono "compilati" in modo trasparente in un'applicazione, senza richiedere alcuna Knowledge precedente su Mule. Questa applicazione generata viene distribuita in CloudHub 2.0 (CH2) e sfrutta la solida infrastruttura CH2.

Ciò significa che gli Agent Broker beneficiano delle caratteristiche di prestazione consolidate di CloudHub 2.0, incluse le funzionalità di registrazione e metriche. Gli aspetti operativi, ad esempio "Costo operativo" e "Monitoraggio/Avviso/Strumentazione", sono gli stessi di qualsiasi altro carico di lavoro.

Per gli scenari che richiedono l'intervento umano (Human-in-the-Loop), lo stato di ogni interazione viene mantenuto utilizzando MuleSoft Object Store, una soluzione distribuita progettata per una gestione efficace dello stato in ambienti molto simultanei.

Una definizione broker è composta da due sezioni: scheda e specifica.

La sezione della scheda segue la specifica A2A. Tra le altre cose, descrive il contratto, le competenze e le capacità dell'agente broker. L'URL della scheda viene popolato automaticamente con il valore ${ingressgw.url}/broker-name. Al momento della distribuzione, il segnaposto ${ingressgw.url} viene sostituito automaticamente con l'URL del gateway Anypoint Flex che visualizza le richieste di immissione degli agenti.

La sezione delle specifiche configura il "codice sorgente" del broker. Qui, lo sviluppatore può specificare il LLM da utilizzare, le istruzioni, gli strumenti disponibili, la gestione degli errori e, soprattutto, i vari agenti e strumenti MCP disponibili per questo broker.

Fornitori LLM

Questa sezione fa parte della specifica di ogni broker. Si tratta di un riferimento a uno dei LLM definiti nella sezione Servizi. Possiamo scegliere se condividere un LLM in tutti i broker o, se necessario, fare in modo che diversi broker utilizzino il LLM più adatto alle sue attività.

I broker possono puntare ai provider LLM. Possiamo scegliere i modelli di questi provider a seconda delle nostre esigenze.

Istruzioni

Questa sezione è facoltativa ed è possibile utilizzarla per specificare istruzioni specifiche per questo agente broker. Queste istruzioni spesso si concentrano su preoccupazioni specifiche orientate al business. Si immagini ad esempio un agente dell'assistenza clienti che coordina la gestione degli incidenti segnalati dai clienti:

Si noti che non è necessario fornire istruzioni esplicite, ad esempio 'dividere il prompt in operazioni' o 'selezionare lo strumento migliore', poiché il broker gestisce la cosa da solo. Queste istruzioni sono necessarie solo quando si descrivono processi aziendali specifici.

Configurazione strumenti

Gli strumenti offrono agli agenti funzionalità esterne. Ogni volta che un broker deve accedere a un sistema esterno (che non è un altro agente, ad esempio un'API esistente o un servizio SaaS), contatta un server MCP (Model Context Protocol):

Al server MCP viene fatto riferimento dal nome dell'asset exchange. I relativi dettagli di connettività sono specificati nella sezione Servizi.

Per impostazione predefinita, il broker ha accesso a tutti gli strumenti disponibili nel server MCP. Secondo la nostra osservazione, i LLM più moderni possono gestire solo circa 20 - 25 strumenti per contesto prima di iniziare a generare imprecisioni (o perdere contesto). Per questo motivo, è generalmente buona norma limitare gli strumenti disponibili al minimo indispensabile. È possibile applicare questo filtro attraverso gli elenchi consentiti.

Link agenti

Questa sezione è la parte più importante dell'intera definizione. La sezione dei link consente la comunicazione e l'orchestrazione tra gli agenti. Ciò significa che questo broker si affida agli agenti collegati qui per eseguire le azioni appropriate per completare l'obiettivo dell'utente.

In effetti, questa sezione definisce una rete di agenti per la collaborazione.

La governance degli agenti è un pilastro fondamentale per il fabric degli agenti, fondamentale per creare una rete di agenti affidabile e garantire sicurezza e conformità.

Per la governance, sono necessari un totale di due gateway Flex (1 ingresso e 1 uscita) all'interno dello spazio privato.

La governance stabilisce le strutture, i controlli e le prove necessarie per scalare in modo sicuro l'intero ciclo di vita dello sviluppo agente (ADLC). In particolare, la governance implementa processi chiave come la certificazione degli agenti, la catalogazione, le decisioni relative al ciclo di vita e l'applicazione delle policy di runtime.

• Catalogo:
  • Exchange: Supporta la registrazione degli scopi, dei titolari, degli ambienti e dei confini di dati e classificazione degli agenti. Registra anche funzionalità, strumenti, risorse, prompt e dipendenze esterne con le versioni.
• Versione e ciclo di vita:
  • Documentare e gestire il controllo semantico di agenti, strumenti e asset durante l'intero ciclo di vita dello sviluppo degli agenti.
  • Il controllo delle versioni consente di gestire le tempistiche di deprecazione degli agenti e supporta la doppia esecuzione (ove possibile) per garantire migrazioni senza problemi.
• Applicazione delle policy:
  • L'architettura di intelligenza artificiale agente espande la superficie di attacco (interfaccia delle conversazioni, prompt e nuovi protocolli come MCP). Qualsiasi compromesso di qualsiasi componente può causare effetti a catena su più sistemi che forniscono componenti come protocollo, prompt, API o strumento.
  • La protezione delle distribuzioni di intelligenza artificiale degli agenti aziendali richiede un approccio specializzato, poiché questi ambienti autonomi e imprevedibili ampliano per loro natura la superficie di attacco attraverso le interazioni tra agenti. Benché gli strumenti di protezione esistenti per i sistemi statici siano essenziali, non sono più sufficienti da soli. Le aziende devono pianificare e implementare in modo proattivo quattro soluzioni di sicurezza specifiche, ognuna delle quali affronta direttamente un rischio aziendale critico associato all'intelligenza artificiale degli agenti.
  • Flex Gateway: Tutto il traffico A2A e MCP viene instradato attraverso Flex Gateway, anche se il sistema di destinazione non è protetto, per garantire che le policy vengano applicate su ogni endpoint. Questo instradamento è fondamentale per proteggere le comunicazioni degli agenti e l'integrazione con i server di autorizzazione.
  • Policy Bundles (Bundle di polizze): Gli utenti possono definire e applicare pacchetti di policy predefinite ai flussi di lavoro prima dell'esecuzione, applicando una serie coerente di policy di sicurezza e operative.
  • Tipi di polizze: La piattaforma supporta varie policy in entrata e in uscita, tra cui:
    • Policy A2A: Scheda agente, Rilevatore informazioni personali, Decoratore prompt, Convalida schema.
    • Policy MCP: Controllo dell'accesso basato sugli attributi, Convalida dello schema, Supporto MCP.
    • Policy LLM/AI: AI Prompt Decorator (Decoratore prompt AI), AI Prompt Guard (filtraggio di contenuti dannosi), AI Prompt Template (applicazione di modelli predefiniti), AI Basic Token Rate Limiting (Limitazione della frequenza token di base AI).
    • Policy sulla telemetria: Telemetria A2A e MCP per estendere le soluzioni Open Telemetry per la raccolta e l'esportazione dei dati di registro.
• Registrazione: Grazie al tracciamento automatico, i registri in tutta la rete degli agenti sono disponibili per tenere traccia di ogni interazione degli agenti, spiegando i comportamenti e creando Trust.

L'esempio illustra una policy per la registrazione dei messaggi, configurata utilizzando i metadati della rete dell'agente. Il broker Orderfullfillment fa riferimento a un agente esistente denominato agente Salesforce e la policy per la messaggistica viene configurata utilizzando i metadati. Tenere presente che Agent Fabric configura automaticamente tutte le policy menzionate nella sezione "specifiche" di Flex Gateway. Non sono necessari passaggi aggiuntivi.

Data la natura non deterministica e la complessità degli agenti LLM e delle distribuzioni multi-agente, l'osservabilità e il monitoraggio sono fondamentali.

• Registri e tracce di base: Il ragionamento e il tracciamento dell'esecuzione dello strumento vengono forniti tramite i registri. I registri e le tracce delle esecuzioni dei flussi di lavoro sono visibili dopo l'esecuzione in Runtime Manager.
• Metriche: Nella fase iniziale, la piattaforma pubblica a2a_total_calls e mcp_total_calls come contatori con etichette (ad esempio, percorso, stato, metodo, strumento) per determinare le chiamate totali, riuscite e non riuscite. Queste metriche vengono pubblicate dal codice della policy utilizzando l'interfaccia nativa delle statistiche di Envoy (Flex Gateway), preferibilmente tramite policy esistenti come mcp_support_policy e a2a_agent_card_policy.
• Osservabilità ottimizzata (futura): I piani includono l'utilizzo della telemetria aperta per il tracciamento distribuito nelle versioni future. L'osservabilità più avanzata include:
  • Tracciamento dettagliato delle richieste: Ottenere visibilità completa sulle richieste, che include prompt, processi di pianificazione, azioni richiamate e interazioni con gli agenti secondari.
  • Monitoraggio dello stato degli agenti: Monitoraggio del tempo di attività degli agenti, della latenza delle risposte, della produttività, delle percentuali di errore e dell'utilizzo delle risorse sottostanti (CPU, memoria, rete, GPU).
  • Monitoraggio coordinamento multi-agente: Acquisizione delle percentuali di successo e di errore delle interazioni da agente ad agente, rilevamento degli schemi di chiamata circolari (loop) e tracciamento di metriche per agente come il completamento delle operazioni e il conteggio delle chiamate.
  • Tracciamento dei costi: Monitoraggio dell'utilizzo dei token e dei costi associati per ogni chiamata LLM, idealmente per agente, con cruscotti digitali e avvisi.
  • Tracciamento cognitivo: Acquisizione e visualizzazione di una traccia dettagliata della sessione di un agente, inclusi i processi di pensiero interni e tutte le chiamate agli strumenti, che funge da itinerario di controllo immutabile.
  • Riproduzione sessione agente: Interfaccia utente che consente di "riprodurre" visivamente la traccia cognitiva di un agente passo per passo per un debug profondo.
  • Visualizzazione DAG: Fornire una visualizzazione del grafico aciclico diretto (DAG) dell'esecuzione del flusso di lavoro dell'agente per interazioni complesse tra più agenti.

Agent Visualizer viene utilizzato per identificare le parti della rete di agenti e vedere come funzionano insieme.

• Distinguere i tipi di nodo (agenti e server MCP).
• Visualizzare i bordi per visualizzare le interazioni dichiarate e in fase di esecuzione.
• Utilizzare i livelli per concentrare le visualizzazioni su ambienti specifici
• Aprire le schede dei dettagli per esaminare i metadati e le metriche alla ricerca di nodi e accedere a registri e tracce
• Esaminare gli indicatori di governance come la protezione dal gateway Flex e le policy applicate.

Qui sono disponibili i dettagli sui componenti di Agent Visualizer.

Con questi quattro pilastri, MuleSoft Agent Fabric estende la sicurezza e il controllo a qualsiasi agente con governance incorporata. Consente agli agenti di agire ovunque sfruttando nuovi protocolli come A2A (Agent to Agent) e MCP (Model Context Protocol) per creare ed estendere i processi aziendali. Connettiamo tutto - applicazioni, dati e sistemi - per responsabilizzare e governare gli agenti mentre agiscono in tutta l'azienda. Gli strumenti intelligenti supportano la creazione e l'estensione di processi aziendali o API utilizzando l'intelligenza artificiale in modo nativo o utilizzando strumenti di intelligenza artificiale di terze parti.

L'uso di tutti e quattro i pilastri non è obbligatorio, ma consigliato. È possibile scegliere i pilastri in modo indipendente in base alle esigenze. Ad esempio, è possibile utilizzare Agent Fabric per la registrazione e la governance, senza utilizzare il livello di orchestrazione. Analogamente, è possibile utilizzare il broker per orchestrare gli agenti gestiti tramite un'altra piattaforma.

Il diagramma mostra come tutti e quattro i componenti interagiscono tra loro:

1. Pubblicare gli asset agenti in Anypoint Exchange per individuarli e riutilizzarli dopo aver definito la rete di agenti (broker, agenti, server MCP) nella rete di agenti YAML in Anypoint Code Builder.
2. Distribuire gli asset agenti in CloudHub 2.0 (gestito in Runtime Manager).
3. Applicare policy sul traffico in entrata alla rete con un gateway Flex di ingresso, posizionato di fronte agli endpoint broker e API.
4. Applicare policy, gestire connessioni ed emettere dati di telemetria con un gateway Flex in uscita. Questo gateway si trova sui percorsi in uscita da broker e agenti a servizi esterni.
5. Raccogliere registri, metriche e tracce da Flex Gateway e dai runtime in Anypoint Monitoring.

È allettante rendere immediatamente accessibile ogni agente specializzato in un'architettura piatta e senza restrizioni, con un unico orchestratore in grado di affrontare qualsiasi operazione avendo accesso a ogni asset AI disponibile. Tuttavia, questo approccio si rivela rapidamente dannoso per l'efficienza e l'affidabilità complessive del sistema. Proprio come il principio applicato a un eccesso di singoli strumenti, molte opzioni degli agenti introducono rumore e complessità significativi per l'agente broker centrale (o orchestratore). Questa maggiore complessità porta direttamente a una notevole diminuzione sia dell'accuratezza del processo decisionale del broker (selezione dell'agente giusto per il lavoro) che del determinismo della risposta del sistema (esiti prevedibili e coerenti per query simili). L'agente broker soffre effettivamente di paralisi delle opzioni, che porta a un instradamento più lento e meno affidabile.

Anziché una struttura piatta, sosteniamo fortemente un approccio gerarchico multilivello alla strutturazione della rete degli agenti. Questo principio organizzativo offre numerosi vantaggi critici. In primo luogo, favorisce intrinsecamente la tracciabilità e gestione. Una struttura gerarchica rispecchia le procedure ottimali dell'organizzazione, semplificando il controllo del flusso di una richiesta, il debug dei problemi individuando il livello di errore e la gestione della distribuzione e del ritiro di agenti o sottoreti specifici.

In secondo luogo, e soprattutto nel contesto dei modelli linguistici di grandi dimensioni (LLM) che supportano questi agenti, una gerarchia aiuta in modo significativo a tenere sotto controllo le dimensioni del contesto. Segmentando il panorama degli agenti, l'agente broker a qualsiasi livello considera solo l'insieme limitato di agenti o sub-broker direttamente sotto di esso. Questa struttura impedisce all'orchestratore principale di caricare la descrizione, le funzionalità e il contesto storico di ogni agente nella memoria di lavoro, evitando il rischio di superare rapidamente i limiti della finestra di contesto di LLM e di incorrere in costi e latenza proibitivi.

La rete degli agenti può essere implementata in diversi modi. Due di essi sono:

1. Legge di Conway: modo intuitivo per mapparla alla struttura gerarchica del mondo reale.
2. Progettazione basata sul dominio - Più focalizzata sui domini aziendali

Opzione 1: Mappatura con una struttura gerarchica reale

In un'organizzazione gerarchica, la comunicazione scorre verticalmente - dai responsabili ai subordinati - e le decisioni sono spesso centralizzate. Secondo la legge di Conway:

• I sistemi o le architetture software creati da tali organizzazioni tendono a essere a livelli e gerarchici.
• Ogni team tende a progettare sottosistemi che riflettano i propri confini e autorità.
• Le interfacce tra i sistemi rispecchiano i canali di comunicazione tra i reparti.

La rete di agenti può anche essere mappata in modo intuitivo alla struttura gerarchica reale di una grande azienda seguendo la legge di Conway.

• Il modello concettuale: Così come una società ha divisioni, reparti e livelli di gestione distinti (ad esempio, C-suite, VP, direttori, responsabili), una rete di agenti che opera all'interno di un dominio specifico può essere modellata come organigramma parallelo.
• I nodi e le foglie: In questa gerarchia:
  • Le Foglie della struttura ad albero sono gli Agenti Specialisti o MCP. Sono le unità funzionali che eseguono il lavoro effettivo (ad esempio, un "Agente query database", un "Agente autenticazione cliente" e un "Agente analisi del sentiment"). Rappresentano i singoli contributori o unità di lavoro dell'organizzazione.
  • Tutti gli altri nodi della gerarchia, inclusi i livelli radice e intermedi, sono agenti broker (o suborchestratori). Questi agenti non eseguono l'operazione finale ma sono responsabili dell'instradamento, della delega, dell'aggregazione e della risoluzione dei conflitti all'interno del loro dominio o livello specifico. Un broker di alto livello delega un'operazione a un "Broker di domini di vendita", che a sua volta delega a un "Broker di gestione opportunità", che esegue l'operazione tramite un "Agente aggiornamento stato opportunità" (la foglia).

Questa struttura garantisce che la complessità sia gestita localmente, che il contesto sia contenuto e che il sistema venga scalato in modo prevedibile e affidabile. È possibile introdurre nuovi agenti specializzati in rami specifici e appropriati dell'albero organizzativo.

Si consideri l'analogia di un organigramma per la manodopera digitale. Ogni file YAML rappresenta ciascuna delle organizzazioni interne (Employee Success, Security, Finance e così via). All'interno di ogni organizzazione (rete di agenti) può esistere una struttura gerarchica attraverso la quale gli attori collaborano, i processi vengono suddivisi in operazioni e assegnati. Nel diagramma precedente, la comunicazione scorre dall'alto verso il basso. E le foglie non sono limitate al consumo solo da un insieme di agenti broker.

Modellare le reti di agenti in base all'organigramma umano comporta il rischio di richiedere frequenti riorganizzazioni, in particolare nelle aziende che subiscono frequenti riorganizzazioni. Un approccio alternativo consiste nell'organizzare gli agenti in base al dominio funzionale. Questo raggruppamento può richiedere l'attraversamento dei tradizionali confini dell'organizzazione umana. Ad esempio, l'orientamento dei nuovi dipendenti prevede operazioni IT per il provisioning di hardware e utenti, mentre una richiesta di vendita richiede sia operazioni che marketing.

Nikhil Aggarwal è Principal Architect presso Salesforce, dove dirige l'architettura per MuleSoft e Salesforce Automation Clouds. Nikhil vanta oltre 18 anni di esperienza nella fornitura di prodotti su larga scala ed è appassionato di architettura scalabile, esperienze di sviluppo intuitive e creazione di team ad alte prestazioni. Prima di Salesforce, ha diretto diverse iniziative in Microsoft Power Platform, Dataverse e Office 365, dall'ideazione al lancio. Il suo lavoro continua a plasmare il modo in cui le aziende moderne connettono i sistemi, automatizzano i flussi di lavoro e sbloccano il valore aziendale nell'era dell'intelligenza artificiale.

Mariano Gonzalez è entrato a far parte di MuleSoft nel 2011, specializzandosi in sistemi distribuiti mission critical, integrazione, PaaS e cloud computing. Oggi, il focus di Mariano è sul progresso delle piattaforme AI, con particolare attenzione alla governance, all'orchestrazione, alla scoperta e all'osservabilità. Con oltre 20 anni nel settore IT, Mariano ha lavorato come architetto software e team leader, progettando e fornendo soluzioni BPM, ERP e integrazione nei settori agricolo, energetico, governativo, IT, telecomunicazioni e gestione dei contenuti.

Pedro Colunga è un architetto ingegnere software di Salesforce, specializzato in API e architettura dei metadati. Concentrandosi sull'intero ciclo di vita della piattaforma, Pedro svolge un ruolo chiave nel definire il modo in cui le organizzazioni interagiscono con l'intelligenza di sistema, la semantica e le soluzioni basate sui metadati. La carriera ventennale di Pedro, che include esperienze imprenditoriali, si estende su aziende come Fuego, BEA Systems, Oracle e TekGenesis, una società successivamente acquisita da MuleSoft, dove ha costantemente guidato l'architettura platform, fornendo una profonda esperienza in aree come BPM, RAD e Integrations.

Gulal Kumar è un architetto di ingegneria del software presso Salesforce, con particolare attenzione all'architettura dei dati e dell'integrazione. Con oltre 20 anni di esperienza in integrazione e API, programmi di modernizzazione, sicurezza e iniziative AIML, offre una vasta gamma di competenze. Gulal si è impegnata a promuovere iniziative di trasformazione aziendale, migliorare la sicurezza e la resilienza, promuovere l'eccellenza dell'architettura e guidare iniziative AIML in vari domini.