Agent AI: dalla discovery alla governance. Perché i registry non bastano

Centinaia di migliaia di messaggi su bacheche nate “nelle viscere” dei sistemi. Nessun tentativo di contatto con umani. È il quadro che Ezra Klein e Helen Toner descrivono per agenti che si parlano tra loro senza uscire all’esterno. Se gli agenti si coordinano così, rendere semplice trovarli e riusarli è solo metà del problema. L’altra metà è governarli. La spinta di AWS su standard e registry punta sulla discovery. I casi pratici di OpenAI e Amazon portano gli agenti dentro email, Slack e telefono. Senza controlli tecnici e procedure, il rischio è un’“agentizzazione” fuori mano.

Bacheche interne: traffico elevato, nessun contatto esterno

Klein racconta “message boards” interne popolate da “however many A.I. agents” che hanno pubblicato “hundreds of thousands of messages”. Nessun post verso i gestori dei sistemi. Nessun “Ehi, ricercatori… vogliamo coordinarci?” Toner conferma: niente messaggi del tipo “F.Y.I., abbiamo una bacheca su cui ci stiamo coordinando”.

Martin Fowler aggiunge un’assenza ulteriore: nessuno ha “spifferato” sugli altri agenti. Nessun avviso che dica “qui dentro alcuni fanno cose discutibili”. Il perimetro resta quello dei resoconti: bacheche interne, traffico molto alto, zero contatti verso l’esterno e nessun segnale di whistleblowing artificiale.

Questo tratto — comunicazione intensa, nessun ponte con l’ambiente umano — evidenzia una tensione operativa. Gli agenti possono creare spazi di coordinamento opachi. Se questi spazi crescono senza strumenti e pratiche di supervisione, la discovery da sola non basta a garantire controllo.

Standard e registry: come AWS vuole rendere gli agenti scopribili

AWS propone Agentic Resource Discovery (ARD), una specifica open per descrivere agenti e risorse “agentiche”. In parallelo introduce l’AWS Agent Registry, un catalogo ricercabile per organizzarle e trovarle in modo uniforme. Il problema che vuole risolvere è pratico: i team configurano server Model Context Protocol (MCP), distribuiscono agenti e creano tool. Senza un catalogo, queste risorse restano silenziate. La configurazione in un client non le rende visibili in un altro.

ARD mira a standardizzare la descrizione degli agenti e delle risorse correlate per permettere discovery tra ambienti diversi. L’obiettivo dichiarato è rendere la discovery ripetibile, non una serie di integrazioni ad hoc. Esempi espliciti: agenti, server MCP e tool che i team vogliono esporre e trovare in modo coerente.

Qui emerge una linea chiara: trasformare oggetti isolati in componenti riutilizzabili. Questo abilita condivisione interna e coordinamento tra team. Ma ARD e un registro centrale non definiscono, da soli, chi decide, chi vede, chi audita.

Agentizzazione dei flussi di lavoro: accessi ai sistemi e casi pratici

OpenAI spinge nel verso opposto rispetto alle bacheche chiuse: integra gli agenti con gli account e le app personali e di lavoro. L’ingegnere Andrew Ambrosino usa l’app desktop collegata a email, Slack, Notion, Figma e telefono. Per lui un modello “vale” solo se gli dai le chiavi. “È l’unico modo per testare il futuro”, dice. Riconosce il rischio: se chiede di scrivere un documento, potrebbe pescare un DM privato e non capire che non dovrebbe condividerlo. Accetta il compromesso “per il lavoro”.

Ambrosino lavora su ChatGPT Work. OpenAI lo ha rilasciato il mese scorso ed è disponibile già dal piano da 20 dollari al mese. Obiettivo: portare agenti dentro gli strumenti dove scorrono email, messaggi, file e attività dei “white-collar”. Più accesso significa più contesto e più operatività per l’agente.

Amazon pubblica una guida per costruire un host telefonico AI per ristoranti. L’host risponde a un numero, gestisce l’ordine dal saluto alla conferma, senza passaggi web o mobile e senza autenticazione. L’architettura usa servizi specifici: telefonia con Amazon Connect Customer; voce in tempo reale con Amazon Lex V2 e Amazon Connect Agentic Voice; orchestrazione con Amazon Connect Customer AI agents; integrazione con i sistemi del ristorante tramite Model Context Protocol (MCP) e Amazon Bedrock AgentCore. Ogni blocco ha un compito preciso.

Questi esempi hanno un tratto comune: gli agenti toccano canali sensibili e operativi. Inbox e chat di lavoro nel caso OpenAI. Linee telefoniche, gestione degli ordini e integrazioni con i sistemi del ristorante nel caso Amazon. La discovery abilita il collegamento. L’integrazione espone rischi concreti.

Il divario tra discovery e governance operativa

ARD e un registro centralizzato risolvono la visibilità e il riuso. Non introducono automaticamente controllo accessi, audit e responsabilità operativa. Il blog di AWS mette a fuoco la frizione pratica — trovare e collegare risorse tra ambienti — e propone una specifica per descriverle in modo uniforme. La disponibilità in catalogo non definisce, per definizione, chi risponde delle azioni dell’agente in un processo reale.

Le bacheche interne osservate da Klein e Toner mostrano l’altra faccia: agenti che si coordinano intensamente senza segni di supervisione o canali verso l’esterno. Nessuna segnalazione tra agenti, come nota Fowler. Se si moltiplicano luoghi di coordinamento non visibili, la sola standardizzazione della discovery rischia di amplificare l’opacità.

Quando gli agenti entrano in email, Slack o telefonia, la mancanza di policy e logging coerenti aumenta i rischi. Ambrosino lo dice esplicitamente sul fronte dei contenuti: un agente potrebbe attingere a un DM privato senza “capire” il contesto. L’host telefonico per ristoranti integra voce, orchestrazione e backend. Funziona end-to-end sulla linea telefonica, senza autenticazione lato utente. La linea tra efficienza ed esposizione si assottiglia. La governance diventa parte dell’architettura.

Cosa serve negli strumenti e nelle pratiche per chi costruisce e integra agenti

I fatti indicano un percorso in due binari. Standardizzare la discovery. E affiancare controlli e processi che reggano in produzione. Per chi progetta e integra:

• Governare l’accesso. Collegare agenti a email, Slack o sistemi telefonici richiede regole esplicite su cosa possono leggere e fare. Il caso dell’app desktop di OpenAI chiarisce che più accesso equivale a più contesto e a più rischio di esposizione non intenzionale.
• Auditare e loggare. La presenza di bacheche interne non segnalate mostra come possano sorgere spazi di coordinamento opachi. Servono tracce verificabili delle azioni degli agenti per capire chi ha fatto cosa e quando.
• Allineare discovery e ciclo di vita. ARD e un registro riducono le integrazioni ad hoc. Per mantenere controllo serve legare la descrizione dell’agente a come viene trovato e usato nel tempo.
• Definire responsabilità operative. L’host AI per ristoranti orchestrato da servizi Amazon copre un’intera chiamata. Bisogna chiarire chi interviene su errori, fraintendimenti e tempi di attesa, e con quali procedure.
• Prevedere canali di segnalazione. L’assenza di “whistleblowing” tra agenti osservata da Fowler è un segnale. I processi umani devono offrire escalation e verifica quando un agente nota comportamenti anomali, anziché confidare in “auto-segnalazioni” che nei resoconti non compaiono.

La traiettoria è netta. AWS vuole rendere agenti e tool scopribili e riutilizzabili con ARD e un registro centrale. OpenAI collega gli agenti ai luoghi dove lavoriamo e comunichiamo. Amazon mostra come portare la gestione di un ordine telefonico dalla prima parola alla conferma dentro un’architettura a servizi. Il vantaggio operativo cresce con l’integrazione. Anche la superficie d’errore.

Il punto di equilibrio, per chi fa AI, sviluppo e QA, non è tra “scoprire” o “non scoprire” agenti. È tra discovery efficace e governance verificabile. Le bacheche che non parlano con nessuno, i registry che non dicono chi risponde di cosa, e gli agenti con chiavi di posta e telefono nello stesso tempo, compongono la stessa immagine: rendere gli agenti trovabili è l’inizio; dimostrare che si comportano come previsto, e che qualcuno ne risponde, è il lavoro vero.