Gli agenti AI stanno entrando nella loro era dei microservizi, ma l'analogia ha dei limiti

StartupHub.ai è approdata su Google News con un'affermazione netta: gli agenti AI occupano oggi la posizione che i microservizi avevano nel 2015. Il paragone segnala l'avvicinarsi di un cambiamento infrastrutturale, nonostante restino aperti interrogativi sulla capacità degli agenti di comportarsi con sufficiente affidabilità per questo tipo di architettura.

L'affermazione è un'analogia, non il lancio di un prodotto né un traguardo misurato in modo indipendente. Il suo valore risiede nel conflitto che mette in luce. Le aziende AI presentano sempre più spesso gli agenti come lavoratori modulari in grado di usare strumenti, scambiarsi compiti e operare tra sistemi aziendali.

Eppure gli agenti non sono normali servizi software. Interpretano linguaggio ambiguo, generano risultati variabili e talvolta intraprendono azioni che i loro progettisti non avevano previsto. Collegare più agenti può moltiplicare queste incertezze invece di contenerle.

I microservizi hanno attraversato una transizione altrettanto difficile. I team hanno ottenuto distribuzione e scalabilità indipendenti, ma hanno poi ereditato nuovi problemi relativi a individuazione dei servizi, tracciamento, autenticazione, latenza e guasti distribuiti. Attorno a queste lacune operative è cresciuta un'industria di prodotti infrastrutturali.

Il mercato degli agenti AI sembra ora seguire parte di quel percorso. Standard come Model Context Protocol, o MCP, collegano le applicazioni AI a strumenti e dati. Agent2Agent, noto come A2A, supporta la comunicazione e la delega tra agenti indipendenti.

Questa somiglianza rende utile l'inquadramento di StartupHub.ai. Non rende inevitabile l'esito. La sfida decisiva è quella tra sistemi di agenti modulari e i controlli operativi necessari per renderli affidabili.

Cosa cambia davvero con l'affermazione su Google News

Il titolo di StartupHub.ai impone al mercato degli agenti un parametro più esigente rispetto a un'altra previsione sul software autonomo.

L'articolo è apparso su Google News con il titolo “AI Agents Are Where Microservices Were in 2015.” Quel titolo non dimostra un risultato tecnico datato. Propone una collocazione lungo la curva di sviluppo del settore.

Il paragone richiama il 2015 perché i microservizi stavano attirando ampia attenzione, mentre l'infrastruttura di supporto restava incompleta. Molte organizzazioni comprendevano la promessa architetturale prima di comprenderne il costo operativo.

I microservizi suddividevano le applicazioni in servizi distribuiti in modo indipendente, con interfacce esplicite. Questo approccio dava ai team maggiore libertà di aggiornare, scalare e sostituire singoli componenti.

Ma spostava anche la complessità dal codice alla rete. Una chiamata di funzione diventava una richiesta remota che poteva andare in timeout, fallire, essere ritentata o restituire una risposta incompatibile.

La versione basata sugli agenti appare familiare. Un'azienda può separare ricerca, pianificazione, programmazione, assistenza clienti o acquisti in agenti specializzati. Un orchestratore può assegnare il lavoro mentre ogni agente usa modelli, strumenti, dati o autorizzazioni diversi.

L'architettura degli agenti di Microsoft documenta direttamente questo schema. Descrive gli agenti come servizi indipendenti collegati tramite API definite o protocolli di messaggistica.

Lo stesso riferimento identifica anche i compromessi. La comunicazione tra agenti aggiunge latenza e modalità di guasto. Il contesto condiviso diventa più difficile da gestire, mentre governance e sicurezza devono attraversare i confini dei servizi.

Queste avvertenze contano perché un agente AI è più di un convenzionale wrapper API. Seleziona azioni a partire da ragionamento generato dal modello, contesto recuperato, descrizioni degli strumenti e istruzioni dell'utente.

Un servizio normale dovrebbe comportarsi in modo prevedibile quando riceve una richiesta valida. Un agente può interpretare lo stesso obiettivo in modo diverso dopo un aggiornamento del modello, un cambiamento di contesto o una risposta di uno strumento.

Questa differenza modifica ciò che l'analogia richiede. I costruttori di agenti non hanno bisogno soltanto di equivalenti per individuazione dei servizi, instradamento e bilanciamento del carico. Hanno bisogno di sistemi che registrino intenzione, delega, evidenze, autorizzazioni e decisioni generate.

Il titolo su Google News sposta quindi l'attenzione dall'intelligenza del modello alla maturità operativa. La domanda rilevante non è più se un agente riesca a completare una dimostrazione impressionante.

La domanda è se i team possano distribuire molti agenti senza perdere visibilità o controllo. Questo standard mette sotto pressione piattaforme di agenti, provider cloud, fornitori di sicurezza e team di ingegneria aziendale.

Spiega anche perché l'infrastruttura sia diventata il centro della conversazione. La prossima fase dipende meno da un altro assistente ben rifinito e più da contratti affidabili tra componenti incerti.

Perché l'infrastruttura degli agenti AI sta convergendo ora

L'infrastruttura degli agenti si sta formando perché gli sviluppatori hanno iniziato a separare l'accesso agli strumenti, la comunicazione tra agenti, l'identità e l'orchestrazione in livelli distinti.

Le prime dimostrazioni di agenti spesso riunivano ogni funzione in un'unica applicazione. Un singolo processo conteneva il prompt, la selezione del modello, le definizioni degli strumenti, la memoria, il ciclo di esecuzione e l'interfaccia utente.

Questo design funziona per gli esperimenti perché gli sviluppatori possono ispezionare un solo codebase e modificare tutti i livelli insieme. Diventa fragile quando nel flusso di lavoro entrano più team, modelli, fornitori o domini di sicurezza.

MCP ha affrontato una parte di questo problema. Il protocollo offre alle applicazioni AI un modo condiviso per individuare e invocare strumenti o recuperare risorse contestuali.

A2A affronta un altro livello. La specifica A2A descrive uno standard attraverso il quale agenti indipendenti possono individuare capacità, scambiarsi compiti e comunicare risultati.

La distinzione è importante. Un collegamento da un agente a un database è diverso da una delega tra due agenti con proprietari separati e processi di ragionamento interni distinti.

Questa divisione ricorda la stratificazione emersa attorno al software distribuito. Gli sviluppatori hanno infine separato la logica applicativa da rete, individuazione dei servizi, telemetria, policy e gestione del deployment.

La recente attività di governance rafforza questo paragone. Axios ha riferito nell'agosto 2026 che il progetto A2A di Google si stava spostando nella Agentic AI Foundation.

Secondo il report sugli standard, la fondazione era passata da meno di 40 membri a oltre 250. Tra i partecipanti figuravano importanti aziende di cloud, modelli, software e commercio.

Il trasferimento colloca A2A vicino a MCP e a progetti correlati sotto una struttura di governance più focalizzata. Questo non garantisce l'interoperabilità, ma mostra che più fornitori riconoscono il problema del coordinamento.

Una governance neutrale può ridurre una fonte di esitazione. Le aziende raramente desiderano che un flusso di lavoro importante resti vincolato al formato interno degli agenti di un singolo fornitore di modelli.

Le interfacce comuni offrono un'alternativa. Un agente per gli acquisti potrebbe delegare l'analisi dei contratti a un fornitore, la revisione della conformità a un altro e il recupero dei dati interni a un servizio controllato dall'azienda.

Questa modularità offre agli acquirenti leva negoziale e flessibilità tecnica. Crea però anche più confini nei quali identità, contesto e autorizzazioni possono fallire.

Ecco perché il paragone con i microservizi è arrivato ora. Le capacità degli agenti sono progredite abbastanza da rendere visibili i problemi di integrazione, mentre gli standard restano abbastanza giovani da competere per l'adozione.

Anche la diversità dei modelli determina il momento. Le aziende scelgono sempre più modelli diversi per qualità del ragionamento, latenza, privacy, modalità o costo operativo.

Un singolo agente monolitico può nascondere questa selezione dietro un'unica interfaccia. Un sistema multi-agente espone le differenze e richiede contratti espliciti tra i componenti.

Gli sviluppatori hanno inoltre bisogno di contesto organizzativo persistente. Un agente non può svolgere un lavoro utile se non dispone di file, decisioni, terminologia e cronologia alla base di una richiesta.

Questo requisito aumenta l'importanza del recupero delle informazioni e del knowledge blending. Tuttavia, un contesto migliore non elimina la necessità di controllo degli accessi o tracciamento delle fonti.

Il livello infrastrutturale deve rispondere a più domande contemporaneamente. Quale agente ha ricevuto il compito, quali dati ha letto, quali strumenti ha chiamato e chi ha approvato l'azione?

Le piattaforme di microservizi hanno infine normalizzato domande comparabili sui servizi e sulle richieste di rete. I sistemi di agenti vi rispondono ancora attraverso log frammentati, tracce specifiche del framework e codice applicativo.

Questa lacuna crea l'opportunità alla base dell'affermazione di StartupHub.ai. Rivela anche quanto il mercato sia ancora lontano da un livello infrastrutturale stabile.

Gli agenti modulari affrontano lo stesso costo dei sistemi distribuiti

Suddividere un flusso di lavoro AI in più agenti può migliorare la specializzazione, ma trasforma anche l'incertezza locale in incertezza distribuita.

I microservizi promettevano proprietà e deployment indipendenti. Questi vantaggi erano reali, soprattutto per le grandi organizzazioni con molti team e requisiti di scalabilità disomogenei.

I costi erano altrettanto reali. I servizi necessitavano di contratti stabili, versionamento, individuazione, tentativi, autenticazione, tracciamento distribuito e meccanismi per gestire guasti parziali.

Gli agenti ereditano ciascuna di queste necessità. Aggiungono comportamento probabilistico, output dei modelli mutevoli, prompt injection, limiti di contesto e deleghe ambigue.

Si consideri un flusso di lavoro per l'assistenza clienti. Un agente classifica la richiesta, un altro recupera i dati dell'account e un altro ancora propone una soluzione.

Un quarto agente potrebbe elaborare un rimborso dopo aver ricevuto l'approvazione. Ogni passaggio trasferisce dati, assunzioni e autorità dalla fase precedente.

Se l'agente di recupero seleziona una policy obsoleta, l'agente di risoluzione può produrre una raccomandazione sicura di sé ma non valida. Un agente per i rimborsi potrebbe quindi eseguire un'azione basandosi su quella raccomandazione.

Il guasto non risiede in un solo componente. Emerge lungo l'intera catena, rendendo meno efficace il debugging convenzionale.

Una traccia che mostra richieste di rete riuscite non può spiegare se un agente abbia frainteso una policy. Una trascrizione del modello non può dimostrare che l'accesso al record del cliente corretto fosse autorizzato.

L'osservabilità degli agenti richiede quindi più livelli. I team hanno bisogno di telemetria di rete, input del modello, chiamate agli strumenti, fonti recuperate, percorsi decisionali ed eventi di approvazione.

Il sistema deve inoltre conservare registri utili senza archiviare informazioni private non necessarie. Il tracciamento dettagliato può diventare esso stesso un rischio per sicurezza e conformità.

I tentativi dimostrano un'altra differenza. Un servizio convenzionale può spesso ripetere un'operazione idempotente, ossia una richiesta identica non produce effetti aggiuntivi.

Un nuovo tentativo da parte di un agente può generare un piano diverso o scegliere un altro strumento. Ripetere una richiesta di acquisto fallita potrebbe creare un secondo ordine, a meno che il sistema circostante non imponga controlli transazionali.

Lo stato aggiunge ulteriore difficoltà. Un agente può memorizzare un riepilogo mentre un altro conserva il documento originale. Le loro conclusioni possono divergere man mano che una delle due rappresentazioni cambia.

La risposta dei microservizi a problemi simili ha incluso schemi espliciti, test dei contratti, registri degli eventi e gestione dello stato distribuito. Le piattaforme per agenti necessitano di equivalenti che tengano conto del comportamento dei modelli.

L'identità dell'agente è un altro controllo mancante. Un servizio normalmente opera con un'identità di workload definita e autorizzazioni limitate.

Un agente può delegare a un altro agente, che a sua volta può delegare nuovamente. Ogni trasferimento solleva interrogativi sul fatto che l'autorità debba viaggiare insieme al compito.

La risposta più sicura raramente è un’eredità di autorizzazioni illimitata. Un agente di ricerca autorizzato a leggere una scheda cliente non dovrebbe automaticamente concedere tale permesso a un agente esterno di pianificazione.

Credenziali di breve durata, accesso con ambito limitato e registrazioni esplicite delle deleghe possono limitare l’esposizione. Tuttavia, i protocolli da soli non applicano le policy dell’organizzazione.

L’architettura modulare modifica anche gli acquisti. Un’impresa può assemblare agenti di vari fornitori mantenendo orchestration e dati sensibili nel proprio ambiente.

Questa configurazione impedisce a un singolo fornitore di controllare l’intero workflow. Allo stesso tempo, rende più difficile attribuire la responsabilità di un incidente.

Il guasto è stato causato dal modello, dal prompt, dal connettore di strumenti, dall’orchestratore, dalla fonte dati o dall’agente ricevente? Ogni fornitore può fornire una difesa tecnicamente plausibile.

Questo problema di accountability distingue l’infrastruttura per agenti dalla normale integrazione di componenti. Il sistema necessita di prove sufficienti per ricostruire non solo cosa è accaduto, ma anche perché è stata concessa l’autorità.

L’analogia con il 2015 resta qui particolarmente solida. I microservizi sono diventati pratici quando le organizzazioni hanno trattato gli strumenti operativi come parte dell’architettura anziché come un’aggiunta opzionale.

Gli agenti richiedono lo stesso cambiamento. Una demo che completa un’attività è solo l’inizio. La prontezza per la produzione inizia quando il sistema sa contenere, spiegare e recuperare da un guasto.

Il vero problema è il comportamento, non la connettività

Un protocollo condiviso può collegare gli agenti, ma non può rendere le loro decisioni corrette, sicure o coerenti.

L’interoperabilità è un importante obiettivo ingegneristico. Riduce il lavoro di integrazione personalizzata e consente agli sviluppatori di sostituire componenti senza ricostruire un intero workflow.

Tuttavia, lo scambio riuscito di messaggi è una definizione ristretta di successo. Due agenti possono comunicare perfettamente pur trasmettendo supposizioni inaccurate, istruzioni non sicure o autorizzazioni eccessive.

Questo limite indebolisce la versione più semplice dell’analogia con i microservizi. I servizi convenzionali implementano percorsi di codice che gli ingegneri possono ispezionare, testare e vincolare.

Gli agenti usano modelli i cui output variano in base a prompt, ordine del contesto, materiale recuperato, descrizioni degli strumenti e comportamento di campionamento. Anche le impostazioni deterministiche non eliminano l’incertezza nei compiti ambigui.

Un agente può inoltre comportarsi in modo errato senza essere compromesso. Potrebbe seguire un’istruzione legittima, usare uno strumento autorizzato e compiere comunque una scelta dannosa.

Questo rischio differisce da un familiare modello di intrusione. I controlli di sicurezza progettati per bloccare gli accessi non autorizzati non impediscono necessariamente azioni autorizzate ma errate.

L’analisi sulla sicurezza degli agenti del NIST del maggio 2026 coglie questa preoccupazione. I partecipanti hanno ampiamente considerato le nuove minacce alla sicurezza degli agenti un ostacolo all’adozione.

L’agenzia ha inoltre riscontrato un ampio consenso sul fatto che le pratiche consolidate di cybersicurezza restino rilevanti. Tuttavia, tali pratiche richiedono adattamenti per i sistemi di agenti.

Questa è la prospettiva scettica che l’entusiasmo per l’infrastruttura spesso ignora. Un routing migliore e la standardizzazione possono aumentare il numero di sistemi raggiungibili da un agente prima che ne migliori l’affidabilità.

Un protocollo universale per strumenti può ridurre i costi di integrazione per applicazioni sicure. Lo stesso protocollo può anche ampliare le conseguenze di un agente manipolato o confuso.

La prompt injection illustra il conflitto. Un agente può recuperare un documento contenente testo progettato per reindirizzarne il comportamento.

Se l’agente tratta quel contenuto come un’istruzione, può divulgare informazioni o invocare strumenti contro l’intento dell’utente. La connessione di rete può rimanere correttamente autenticata per l’intera durata dell’incidente.

I sistemi multi-agente ampliano la superficie d’attacco perché contenuti non affidabili possono viaggiare tra componenti. Un agente può trasformare testo malevolo in un riepilogo apparentemente affidabile.

L’agente ricevente non dispone quindi del contesto originale necessario per riconoscere la manipolazione. La delega può riciclare istruzioni rischiose attraverso un workflow altrimenti valido.

Gli sviluppatori necessitano di confini che distinguano dati, istruzioni, policy e approvazioni degli utenti. Tali distinzioni devono sopravvivere a ogni messaggio e trasformazione.

Hanno inoltre bisogno di metodi di valutazione che testino workflow completi, non soltanto le singole risposte del modello. Un agente di pianificazione può superare test isolati ma fallire quando un altro agente fornisce un contesto incompleto.

Le attività di lunga durata introducono un’altra incertezza. Un agente che opera per ore incontra file, credenziali, condizioni di rete e stato aziendale in cambiamento.

Il suo piano originale può diventare invalido prima che l’esecuzione termini. Il sistema deve rilevare tale cambiamento e richiedere conferma anziché proseguire sulla base di supposizioni obsolete.

L’approvazione umana offre un controllo, ma la progettazione dell’approvazione conta. Un prompt vago che chiede se “continuare” fornisce al revisore pochi elementi per giudicare.

Un’approvazione utile dovrebbe descrivere l’azione prevista, la risorsa interessata, le prove, l’ambito e le conseguenze reversibili. Le azioni ad alto impatto richiedono una conferma più forte rispetto al recupero in sola lettura.

Le aziende devono inoltre decidere dove l’autonomia sia giustificata. Un agente che redige un riepilogo interno presenta un rischio diverso da uno che invia pagamenti o modifica l’infrastruttura di produzione.

Questa distinzione favorisce un’implementazione incrementale. I team possono iniziare con attività in sola lettura, output misurati e chiari percorsi di escalation.

Possono aggiungere diritti di esecuzione solo dopo aver raccolto prove sui tassi di errore e sul recupero. Questa progressione somiglia più a una graduale estrazione di servizi che a una migrazione immediata verso reti autonome di agenti.

Il mercato potrebbe comunque produrre un equivalente, per gli agenti, di una service mesh. Probabilmente gestirebbe identità, policy, routing, telemetria e controlli standardizzati attorno alle interazioni tra agenti.

Tuttavia, non può sostituire il giudizio a livello applicativo. Nessun livello infrastrutturale può decidere il tasso di errore accettabile o il confine di approvazione per ogni organizzazione.

Ecco perché la connettività non dovrebbe essere scambiata per maturità. Il mercato degli agenti ha iniziato a standardizzare la comunicazione prima di standardizzare un comportamento affidabile.

Chi subirà pressione con la maturazione dello stack

Lo stack emergente mette sotto pressione le piattaforme chiuse per agenti, gli acquirenti aziendali e i fornitori di infrastrutture per ragioni diverse.

Le piattaforme chiuse subiscono la pressione delle interfacce aperte. Se le imprese possono collegare modelli, strumenti e agenti attraverso protocolli condivisi, ottengono maggiore libertà di sostituire singoli fornitori.

Un fornitore può ancora differenziarsi attraverso la qualità del modello, la sicurezza, l’hosting o applicazioni specializzate. Diventa più difficile difendere una piattaforma basandosi esclusivamente su connettori proprietari.

I fornitori cloud affrontano un’altra sfida. Vogliono offrire il control plane preferito senza apparire come se intrappolassero i clienti in un unico modello o framework.

Supportare protocolli aperti può attenuare questa preoccupazione. Può anche ridurre il controllo del fornitore sul livello applicativo.

Gli sviluppatori di framework per agenti devono decidere quali responsabilità appartengano alle loro librerie. La sola orchestrazione dei prompt sta diventando insufficiente per l’uso in produzione.

I clienti necessitano sempre più di valutazione, tracing, applicazione delle policy, gestione delle credenziali, recupero e gestione delle versioni. Aggiungere ogni funzione può trasformare un framework leggero in una piattaforma complessa.

Le aziende di observability acquisiscono un’opportunità, ma le tracce degli agenti richiedono dati non familiari. Il conteggio dei token e la latenza non spiegano se una decisione delegata fosse giustificata.

Un sistema utile deve collegare gli eventi tecnici al significato aziendale. Dovrebbe mostrare quali prove hanno supportato un’azione e quale policy l’ha autorizzata.

I fornitori di sicurezza affrontano la stessa espansione. I controlli di rete e i sistemi di identità restano necessari, ma gli agenti creano rischi decisionali all’interno di sessioni valide.

I fornitori devono monitorare l’uso degli strumenti, le catene di delega, i dati contestuali e l’intento in evoluzione. Una sorveglianza eccessiva può esporre prompt e documenti sensibili, quindi la raccolta richiede disciplina.

Gli acquirenti aziendali sostengono il maggior onere immediato. L’adozione di protocolli non produce un modello operativo, una struttura di accountability o una policy di rischio accettabile.

I team necessitano di responsabili per identità degli agenti, permessi degli strumenti, fonti dati, valutazioni, incidenti e regole di approvazione. Queste responsabilità spesso attraversano i dipartimenti di ingegneria, sicurezza, legale e business.

Anche la gestione della conoscenza diventa infrastruttura operativa. Gli agenti non possono lavorare in modo affidabile a partire da documenti dispersi la cui autorità, aggiornamento e proprietà restano poco chiari.

Una base di conoscenza tecnica ricercabile può migliorare il recupero delle informazioni. I team necessitano comunque di policy per fonti in conflitto e linee guida obsolete.

Le startup che costruiscono infrastrutture per agenti affrontano un problema di tempistica. I clienti riconoscono il problema, ma standard e scelte architetturali restano irrisolti.

Costruire attorno a un unico protocollo può accelerare l’adozione oggi. Può creare lavoro di migrazione se cambiano i requisiti di governance, trasporto o sicurezza.

Il mercato dei microservizi ha prodotto molti strumenti scomparsi quando le piattaforme cloud ne hanno assorbito le funzioni. Le startup nel settore degli agenti affrontano un rischio simile.

Alcune categorie diventeranno attività indipendenti. Altre diventeranno funzionalità all’interno di cloud, piattaforme di modelli, strumenti per sviluppatori o prodotti di sicurezza esistenti.

L’analogia dovrebbe quindi guidare l’architettura più della certezza negli investimenti. Identifica dove si accumula la pressione operativa senza prevedere quali fornitori la cattureranno.

I prodotti più difendibili probabilmente risolveranno problemi che persistono tra modelli e framework. Identità, valutazione, observability, policy ed esecuzione affidabile corrispondono a questa descrizione.

Anche queste categorie restano collegate. Un sistema di valutazione necessita di dati di traccia, mentre un motore di policy necessita di identità e informazioni contestuali.

Lo stack potrebbe consolidarsi attorno a formati di eventi condivisi e controlli di governance. In alternativa, le grandi piattaforme potrebbero fornire sistemi integrati con adattatori ai margini.

Entrambi gli esiti preservano il conflitto centrale. Gli acquirenti desiderano una scelta modulare, ma vogliono anche un soggetto responsabile quando un workflow fallisce.

I microservizi non hanno mai eliminato questa tensione. Le organizzazioni hanno bilanciato componenti indipendenti con il costo di gestire sistemi distribuiti.

Gli agenti AI intensificano questo equilibrio perché i componenti non si limitano a fallire. Possono completare l’attività sbagliata pur apparendo tecnicamente sani.

Cosa dovrebbero osservare i lettori di Google News

Tre segnali mostreranno se gli agenti AI stanno ripetendo la fase produttiva dei microservizi o soltanto la loro complessità.

Il primo segnale è una reale interoperabilità tra fornitori. Un protocollo conta quando un’impresa può sostituire un agente o un modello senza riscrivere il workflow circostante.

Le dimostrazioni tra progetti sotto la stessa fondazione non bastano. Gli acquirenti necessitano di implementazioni indipendenti che preservino stato dell’attività, identità, permessi e gestione degli errori.

Il passaggio di A2A a una governance aperta e focalizzata rafforza l’argomento a favore dell’interoperabilità. Il prossimo test è se piattaforme concorrenti implementeranno comportamenti compatibili oltre il semplice scambio di messaggi.

Osservate test di conformità, descrizioni condivise delle capacità e risultati pubblici di compatibilità. Questi sviluppi rafforzerebbero l’analogia con StartupHub.ai.

Estensioni persistenti specifiche dei fornitori la indebolirebbero. Suggerirebbero che i protocolli servono da involucri comuni, mentre il comportamento significativo resta proprietario.

Il secondo segnale è un’affidabilità di produzione misurabile. I fornitori di agenti mostrano spesso tassi di completamento in valutazioni circoscritte, ma le imprese necessitano di prove a livello di workflow.

Misure utili includono chiamate errate agli strumenti, tentativi di azioni non autorizzate, successo del recupero, frequenza delle approvazioni e guasti causati da contesto obsoleto.

Tali misure devono riflettere ambienti reali, non dimostrazioni selezionate con cura. Dovrebbero inoltre distinguere gli errori del modello dai guasti di integrazione, dati, autorizzazioni e orchestrazione.

Metriche di produzione chiare rafforzerebbero il confronto con il software distribuito maturo. Una continua dipendenza da storie di successo aneddotiche lo indebolirebbe.

Il terzo segnale riguarda un'infrastruttura pratica per identità e autorizzazioni. Gli agenti necessitano di identità verificabili, credenziali con ambito definito e registri di delega che funzionino oltre i confini organizzativi.

Il NIST ha inserito l'identità e la sicurezza degli agenti nella propria agenda degli standard. La sua iniziativa sugli standard riflette il crescente interesse per linee guida volontarie e il coordinamento del settore.

Il test decisivo è verificare se tali sforzi producano modelli implementabili. Le aziende hanno bisogno di controlli compatibili con i sistemi di identità esistenti e in grado di preservare l'accesso con privilegi minimi.

Il principio del privilegio minimo consiste nel concedere soltanto le autorizzazioni necessarie per un'attività specifica. Diventa più difficile da applicare quando un agente modifica il proprio piano o delega dinamicamente il lavoro.

Un sistema pratico dovrebbe restringere l'autorità man mano che un'attività procede lungo la catena. Non dovrebbe copiare ampie autorizzazioni dell'utente a ogni agente partecipante.

I progressi su questo problema rafforzerebbero l'idea che l'infrastruttura degli agenti stia entrando in una fase di piattaforma duratura. Una continua dipendenza da chiavi API condivise la indebolirebbe.

I lettori dovrebbero inoltre valutare con cautela i futuri titoli di Google News. L'espressione “agente AI” oggi comprende assistenti, flussi di lavoro scriptati, strumenti di coding e sistemi dotati di autonomia significativa.

Questi prodotti comportano rischi diversi e non dovrebbero condividere un'unica valutazione di maturità. Un assistente affidabile per la stesura di bozze non dimostra che agenti finanziari o operativi autonomi siano pronti.

Il titolo di StartupHub.ai funziona perché offre al settore un utile riferimento storico. Fallisce se i lettori interpretano il confronto come prova che il risultato sia già arrivato.

I microservizi nel 2015 offrivano un'architettura riconoscibile con un modello operativo ancora incompleto. Gli agenti AI mostrano oggi lo stesso schema generale, ma comportano un onere comportamentale maggiore.

L'opportunità infrastrutturale è reale. Lo è anche il pericolo di distribuire decisioni inaffidabili tra più strumenti, dati e organizzazioni.

Gli sviluppatori dovrebbero chiedersi se ogni confine tra agenti disponga di un contratto, un'identità, una traccia, un fallback e un responsabile chiari. Gli acquirenti aziendali dovrebbero pretendere prove derivanti da flussi di lavoro completi prima di ampliare le autorizzazioni.

I knowledge worker dovrebbero monitorare a quali risorse gli agenti possono accedere e quali azioni richiedono approvazione. La comodità non dovrebbe cancellare la differenza tra preparare un lavoro ed eseguirlo.

La conferma più forte non sarà un'altra ambiziosa dimostrazione di agenti. Sarà un noioso sistema di produzione che fallisce in modo visibile, limita i danni e si riprende in modo prevedibile.

È questo il traguardo che i lettori di Google News dovrebbero monitorare. Finché non verrà raggiunto, l'analogia con i microservizi resterà una mappa utile, non la prova della destinazione.