Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Gli agenti incontrano la multi-tenancy
È facile pensare agli agenti come elementi costitutivi in cui gli agenti sono visti come una serie di componenti autonomi assemblati per supportare le esigenze di un dominio o di un problema aziendale specifico. La cosa diventa più interessante quando iniziamo a pensare a come questi agenti vengono impacchettati e utilizzati dai provider. Per molti aspetti, un agente diventa una fonte di costi e ricavi per un'azienda. I fornitori di agenti devono considerare le diverse persone che utilizzano i loro servizi, il profilo di consumo delle persone e le strategie di monetizzazione che consentono ai fornitori di agenti di creare modelli di prezzi e livelli in linea con i consumatori.
I fornitori di agenti potrebbero supportare diversi modelli per l'implementazione dei propri agenti per soddisfare le esigenze dei clienti. Il diagramma seguente mostra una visione concettuale dei due principali modelli di distribuzione degli agenti.
Il lato sinistro del diagramma mostra il modello di agente dedicato al cliente. Un fornitore di agenti crea un agente implementando un'istanza di agente separata per ogni cliente registrato. Con questo approccio, le capacità dell'agente e la sua capacità di acquisire conoscenze sarebbero limitate all'ambito dell'ambiente di un determinato cliente. Ciò finisce per rappresentare un'esperienza per cliente che eredita alcune delle complessità e dei vantaggi del supporto di ambienti dedicati ai clienti.
Al contrario, il diagramma sul lato destro del diagramma presenta un singolo agente che viene distribuito nell'ambiente del provider. L'agente elabora le richieste di più clienti, evolvendole e apprende sulla base dell'esperienza collettiva di tutti i clienti. Ogni nuovo cliente aggiunto rappresenterebbe semplicemente un altro cliente valido dell'agente. L'agente funziona come un modello Agent as a Service (AaaS), utilizzando costrutti condivisi per supportare le esigenze del cliente. In entrambi i casi, gli agenti consumatori possono essere applicazioni, sistemi o anche altri agenti.
Esistono due modi per considerare il modello AaaS. Il modello sopra riportato offre la stessa esperienza a tutti i clienti. Ciò significa che gli interni dell'agente non includeranno alcun livello di specializzazione che consideri il contesto del cliente richiedente. In genere, per questa modalità, si presuppone che la natura dell'ambito, degli obiettivi e del valore di un agente sia incentrata su un insieme condiviso di risorse, conoscenze e risultati applicati universalmente a tutti i clienti.
L'approccio alternativo all'AaaS prevede che il contesto dei clienti influenzi l'esperienza e l'implementazione dell'agente. Il diagramma seguente fornisce una visione concettuale dell'impronta di un agente AaaS in questo contesto.
In questa visualizzazione AaaS, l'origine e il contesto delle richieste in arrivo influiscono in modo significativo sull'impronta dell'agente. Le risorse, le azioni e gli strumenti che fanno parte dell'implementazione sottostante dell'agente possono variare per ogni richiesta del tenant in entrata. Il valore di un agente è legato alla sua capacità di utilizzare il contesto del tenant per ottenere azioni e risultati influenzati dallo stato del tenant, dalle conoscenze e da altri fattori. Alcune richieste possono produrre un risultato unico per il tenant, mentre altre possono portare a risultati più personalizzati per ogni tenant. Ciò aggiunge una nuova dimensione alla capacità di apprendimento dell'agente, che potrebbe includere una maggiore contestualità e l'acquisizione e l'applicazione delle conoscenze che migliorano i risultati mirati.
Per i provider, il modello AaaS offre molti vantaggi. Poiché più clienti utilizzano un solo agente, il provider ha maggiori opportunità di realizzare economie di scala, promuovere l'efficienza operativa, controllare i costi e creare un'esperienza di gestione unificata. Ciò ha il potenziale per una maggiore agilità, innovazione e crescita per il business degli agenti.
Queste qualità si sovrappongono agli stessi principi che guidano l'adozione del modello SaaS (Software as a Service). In sostanza, il modello AaaS è costruito come un servizio multi-tenant che eredita molti degli stessi attributi di scala, resilienza, isolamento, onboarding e operativi presenti in un ambiente SaaS. Per molti aspetti, l'esperienza AaaS si ispira molto alle strategie e alle pratiche utilizzate dai provider SaaS, ma è ragionevole separare questi termini. Per i nostri scopi, l'accento è posto principalmente sulle implicazioni derivanti dagli agenti edili e operativi che richiedono un supporto multi-tenant.
Per un sistema in grado di trattare tutti gli utenti allo stesso modo e che non richieda la gestione di dati persistenti, sensibili o specifici del cliente, il concetto di locazione avrebbe un impatto minimo sugli agenti. Per i sistemi che dovrebbero servire più clienti preservando l'isolamento dei dati, la personalizzazione e la consapevolezza del contesto, il supporto di più tenant potrebbe essere un elemento essenziale della progettazione, della strategia e dell'obiettivo di un agente. Il diagramma seguente mostra come la multi-tenancy può essere utilizzata in ambienti agentici.
Sul lato sinistro di questo diagramma c'è una classica architettura multi-tenant. Include un'applicazione Web e una serie di microservizi che implementano la logica aziendale. Più tenant utilizzano l'infrastruttura condivisa di questo ambiente, scalabile per soddisfare i mutevoli carichi di lavoro di una popolazione di inquilini in continua evoluzione. L'ambiente è gestito e gestito da un unico pannello di controllo per tutti gli inquilini.
Immagina come questo modello mentale corrisponda all'agente sul lato destro di questo diagramma. Un agente esegue un modello AaaS utilizzato da uno o più tenant. Gli agenti potrebbero provenire da più provider e il contesto dei tenant fluisce tra di loro, poiché una singola istanza di un agente deve elaborare le richieste di più tenant.
L'esempio al centro di questo diagramma è un modello ibrido in cui gli agenti fanno parte dell'esperienza SaaS complessiva. Alcune parti del sistema sono implementate in un modello più tradizionale e altre parti del sistema si basano su agenti. È probabile che questo modello sia comune a molte offerte SaaS, in particolare per le organizzazioni che stanno passando a un'esperienza agentica. È normale che questo modello persista perché non tutti i sistemi vengono forniti come puro modello AaaS. Si noti inoltre che la multi-tenancy si applica ancora agli agenti del modello. Sebbene gli agenti possano essere incorporati in un sistema, possono comunque elaborare le richieste di più tenant.
È naturale chiedersi se la multi-tenancy sia davvero importante. Si potrebbe sostenere che un agente elabora le richieste, quindi supportare la locazione potrebbe avere scarso effetto. Tuttavia, man mano che approfondiamo le implicazioni degli agenti multi-tenant, la locazione può influire direttamente sul modo in cui gli agenti influenzano il modo in cui gli agenti influenzano il modo in cui gli strumenti, la memoria, i dati e altre parti degli agenti vengono accessibili, distribuiti e configurati per supportare i singoli tenant. La locazione influenza anche il modo in cui la scalabilità, la limitazione, la determinazione dei prezzi, la suddivisione in più livelli e altri aspetti aziendali si applicano all'architettura dell'agente.
Uno dei punti salienti di questa situazione è che esistono casi d'uso agentici che richiedono un supporto multi-tenancy. La sfida consiste nel determinare in che modo la multi-tenancy influenzi il design e l'architettura complessivi della vostra esperienza agentica. Per alcuni agenti, il supporto multi-tenant rappresenta una capacità di differenziazione, che consente agli agenti di applicare un contesto specifico del tenant agli agenti che forniscono risultati mirati.
Nelle sezioni successive, vedrete come saranno utili la terminologia e i modelli di progettazione che creiamo per descrivere le architetture SaaS multi-tenant. Questi concetti possono essere adottati dal modello AaaS prendendo in prestito aspetti utili, che introduce nuovi concetti specifici per agente laddove necessari.
Identità, contesto degli inquilini e sistemi agentici
L'aggiunta del contesto del tenant ai singoli agenti non è particolarmente impegnativa. In molti casi, i team possono fare affidamento su meccanismi tipici che vincolano utenti e sistemi agli inquilini e trasferiscono token che riconoscono i tenant agli agenti. Questo è importante se consideriamo in che modo il contesto e l'identità dei tenant supportano più agenti. In questo modello, gli inquilini devono essere legati a un'identità che comprenda tutti gli agenti che collaborano.
In generale, il dominio agentico richiede un modello di identità più trasversale, in linea con le esigenze attuali ed emergenti dei sistemi agentici. I provider di agenti richiedono meccanismi di identità che supportino modelli di sicurezza, conformità e autorizzazione esclusivi forniti con i sistemi operativi agentic. Ciò è particolarmente difficile in ambienti in cui i sistemi sono composti da clienti o altri agenti. Ogni agente integrato deve collegare la propria identità e il contesto del tenant alle interazioni con gli agenti. Il diagramma seguente evidenzia le potenziali sfide relative all'identità e al contesto del tenant che fanno parte delle agent-to-agent interazioni (a2a).
Questo diagramma mostra una serie di agenti creati dal provider che interagiscono come parte del sistema agentico trattato. Ora è stato aggiornato con l'identità e il contesto degli inquilini. Questo scenario è un esempio di sistema agentico che supporta più punti di ingresso. Partiamo dal presupposto che ogni agente di questo sistema richieda il proprio meccanismo di autenticazione per assegnare il sistema o l'utente a un determinato tenant. Man mano che questi agenti interagiscono, il contesto del tenant viene passato a un token web JSON (JWT) che verrà utilizzato per autorizzare l'accesso e inserire il contesto del tenant nell'agente.
Concettualmente, la differenza principale rispetto a questo scenario è che gli agenti si implementano e operano in modo indipendente, il che significa che ogni agente deve essere in grado di determinare la propria identità e autorizzare l'accesso. La chiave è che la sua identità deve avere una certa capacità distribuita di gestire le esigenze del più ampio sistema agentico. È inoltre necessario un allineamento sul modo in cui gli agenti condividono il contesto degli inquilini.
Applicare il valore aziendale SaaS al modello AaaS
In generale, quando consideriamo l'utilizzo di qualsiasi sistema all'interno di un as-a-service modello, consideriamo la natura dell'esperienza e il modo in cui la sua impronta tecnica e operativa determina i risultati aziendali. Quando adottano il SaaS, ad esempio, le organizzazioni utilizzano economie di scala, efficienze operative, profili di costo e agilità per promuovere crescita, margini e innovazione.
È probabile che gli agenti forniti come AAAs perseguano risultati aziendali simili. Supportando più inquilini, un agente può allineare il consumo di risorse alle attività degli inquilini. In questo modo si ottengono economie di scala tipiche degli ambienti SaaS tradizionali. Il modello AaaS consente inoltre alle organizzazioni di gestire, utilizzare e distribuire gli agenti in modo da consentire rilasci frequenti e favorire l'agilità dei fornitori di agenti. La chiave è che il modello AaaS non dipende dalla tecnologia. Crea e guida strategie aziendali che promuovono la crescita, semplificano l'adozione e semplificano le operazioni.
