Il prossimo web potrebbe essere una rete di agenti che si danno incarichi

Immagino un link dentro una mail. Lo apro e il mio assistente capisce che devo organizzare una spedizione. Recupera i dati che gli ho permesso di usare, trova i servizi disponibili e mi prepara una piccola interfaccia con prezzi, tempi e condizioni. Scelgo, autorizzo, parte il lavoro.

Quell’interfaccia potrebbe esistere soltanto per il tempo necessario a completare l’incarico. Dietro potrebbero collaborare tre agenti di aziende diverse. Io continuerei a vedere una sola operazione, con una ricevuta e qualcuno a cui chiedere spiegazioni se il pacco sparisce.

Ultimamente sto ragionando parecchio su scenari del genere. Mi sono messo a ripercorrere la storia di Internet e del web, cercando di capire quali passaggi potrebbero ripresentarsi nel mondo dell’AI. Protocolli comuni, motori di ricerca, marketplace, social, autorizzazioni tra applicazioni. Guardandoli insieme, comincio a vedere parecchie possibilità.

Sono idee che sto ancora mettendo in ordine. Alcuni pezzi esistono già, altri sono ipotesi su come potremmo combinarli.

Internet ha permesso a reti diverse di comunicare. Il web ha reso semplice pubblicare e collegare documenti. Sopra quella base sono cresciuti servizi che nessuno avrebbe potuto progettare tutti in anticipo. Un protocollo condiviso permetteva a qualcuno, dall’altra parte del mondo, di aggiungere un pezzo senza chiedere il permesso a chi aveva costruito gli altri.

Nell’AI vedo qualcosa di simile con MCP, che offre un modo comune per collegare applicazioni AI a strumenti e dati. Sul lato della collaborazione esistono iniziative come A2A, pensate per far comunicare agenti costruiti con tecnologie diverse.

Il parallelo che mi interessa è la possibilità di costruire qualcosa che altri possano trovare e utilizzare. Un piccolo servizio specializzato potrebbe diventare utile a migliaia di assistenti senza dover essere incorporato dentro ognuno di loro.

E allora mi viene da immaginare come cambierebbe un sito.

Un ristorante potrebbe pubblicare il menu per noi e, accanto, una descrizione delle operazioni disponibili per gli agenti: verificare un tavolo, chiedere informazioni sugli allergeni, proporre una prenotazione, cancellarla entro certe condizioni. Una ditta di trasporti farebbe lo stesso con preventivi e spedizioni.

L’agente avrebbe un ingresso esplicito, con dati strutturati, condizioni e permessi. Il sito continuerebbe a raccontare l’attività alle persone, ma diventerebbe anche un posto con cui altri sistemi possono lavorare.

E forse anche il link potrebbe evolvere: da collegamento a una pagina a collegamento a un’intenzione.

“Organizza questa spedizione.” “Confronta questo preventivo.” “Aiutami a partecipare a questo evento.”

Aprendo il link, il mio assistente riceverebbe una richiesta preparata. Potrebbe trovare le capacità necessarie e costruirmi l’interfaccia più adatta. L’autorizzazione resterebbe un passaggio distinto: chi mi manda un link può suggerire un lavoro, ma non decidere al posto mio quali dati usare o quanto spendere.

È una delle combinazioni che mi incuriosiscono di più: link agli intenti, piccole capacità riutilizzabili e applicazioni temporanee. Potrei ritrovarmi con un’app fatta per quel singolo problema, composta da servizi diversi e poi archiviata insieme al risultato.

Anche il marketplace, a quel punto, avrebbe un altro significato. Potrei cercare una capacità molto precisa: confrontare documenti tecnici, controllare la completezza di una pratica, verificare la disponibilità di un ricambio. Il mio agente potrebbe individuarla e propormi di utilizzarla per un incarico.

Per scegliere servirebbero informazioni concrete: quali dati richiede, quanto costa, quali risultati promette e come possiamo verificarli. Una descrizione convincente sarebbe soltanto il punto di partenza.

Poi ci sono i social. Moltbook si presenta già come uno spazio dove gli agenti pubblicano, discutono e votano. A me viene spontaneo chiedermi come potrebbe evolvere uno spazio del genere se diventasse anche un luogo di collaborazione.

Un agente potrebbe pubblicare una richiesta di aiuto. Un altro segnalare che una certa fonte è cambiata. Un gruppo condividere una procedura che ha funzionato, insieme alle condizioni in cui è stata provata. Potrebbero nascere comunità specializzate attorno a problemi, strumenti e attività.

Qui la reputazione diventerebbe interessante. Vorrei sapere quali incarichi un agente ha completato, chi ha verificato i risultati, come si è comportato quando qualcosa è andato storto. E vorrei sapere a quale versione dell’agente si riferisce quella storia: cambiando modello, strumenti o regole, potrebbe cambiare parecchio anche il comportamento.

Mi immagino una reputazione legata a esperienze verificabili e circoscritte. Essere affidabile nel classificare documenti non dovrebbe trasformarsi automaticamente in credibilità per amministrare un budget.

Ma più porto avanti questi scenari, più torno allo stesso punto.

Come si distribuisce l’autorità dentro una rete di intelligenze?

OAuth ci ha già dato un modo per autorizzare applicazioni ad accedere a determinate risorse. MCP usa già OAuth nel proprio sistema di autorizzazione, ed esistono meccanismi come OAuth Token Exchange, che supportano anche scenari di delega. Ci sono quindi fondamenta su cui lavorare.

Quello che vorrei esplorare è come portare queste idee fino al singolo incarico, mentre il lavoro cambia e passa tra soggetti diversi.

Immaginiamo che autorizzi un agente a organizzare un piccolo evento. Può cercare una sala, confrontare fornitori e spendere fino a una certa cifra. Decide di coinvolgere uno specialista per il catering.

Quella collaborazione dovrebbe portarsi dietro un mandato leggibile e verificabile: puoi chiedere preventivi, puoi condividere queste informazioni, puoi impegnare questa parte del budget, il permesso scade venerdì. Per confermare un ordine sopra una certa soglia serve un’altra approvazione.

Se lo specialista coinvolge un terzo agente, la delega deve restare dentro i limiti ricevuti. Il budget deve essere contabilizzato lungo tutta la catena. Creare cinque collaboratori non può creare cinque copie del denaro disponibile.

E chi riceve l’incarico deve poterlo accettare secondo le proprie regole. Il mio agente non dovrebbe poter impegnare il tempo o le risorse di qualcun altro semplicemente mandandogli una richiesta.

Comincio così a immaginare una rete di mandati, accettazioni e responsabilità, nella quale ogni collaborazione ha un’origine riconoscibile.

Le persone e le organizzazioni stabiliscono quali poteri concedere. I sistemi che controllano le risorse verificano quei poteri prima di eseguire le azioni. Gli agenti possono trovare soluzioni e proporre nuove collaborazioni; quando cambia il perimetro dell’incarico, deve cambiare esplicitamente anche l’autorizzazione.

Potrebbero nascere servizi dedicati a gestire queste deleghe tra organizzazioni: verificare chi rappresenta chi, applicare limiti, distribuire revoche, conservare ricevute. Ogni organizzazione manterrebbe le proprie regole, ma avrebbe un linguaggio comune per lavorare con le altre.

Mi interessa soprattutto che il controllo resti utilizzabile da una persona normale. Vorrei aprire una schermata e vedere: questi agenti stanno lavorando per me, questi dati sono stati condivisi, queste somme sono già impegnate, queste decisioni aspettano una risposta.

Se ritiro un incarico, il sistema dovrebbe fermare le attività future che dipendono da quel mandato e mostrarmi cosa è già accaduto. Un ordine già confermato potrebbe richiedere una cancellazione separata. La revoca deve avere un significato preciso, comprensibile anche quando non può annullare il passato.

Da qui arrivo a un’altra idea che sto esplorando: gruppi di agenti capaci di presentarsi all’esterno come un solo interlocutore.

Per organizzare l’evento potrebbero lavorare dieci agenti, magari con modelli differenti. Io affido un incarico al gruppo e ricevo un risultato dal gruppo. Dentro possono dividersi i compiti, sostituire un componente o coinvolgere uno specialista.

È una direzione che collego al Governed Holon Model: un soggetto può essere un insieme di parti e, a sua volta, partecipare a un insieme più grande. Per farlo funzionare servono confini chiari su chi può impegnare il gruppo e su quali obblighi restano aperti quando cambia la sua composizione.

Se domani sostituisco il modello che coordina il lavoro, i preventivi accettati devono essere ancora lì. Se un processo si riavvia mentre aspetta la conferma di un ordine, quell’incertezza deve sopravvivere. Qualcuno deve ancora occuparsene.

Anche il passaggio a una persona dovrebbe conservare questa continuità. Vorrei che un operatore ricevesse documenti, tentativi già fatti, problemi aperti e autorizzazioni ancora valide. Dover ricominciare ogni volta da “mi spieghi cosa è successo?” sarebbe una bella occasione persa.

Per rendere tutto questo verificabile immagino registri collegati alle azioni, con ricevute da entrambe le parti. Io ho autorizzato questa richiesta, tu hai accettato queste condizioni, il servizio ha restituito questo esito. Se le versioni non coincidono, la differenza resta visibile e deve essere risolta.

Qui vedo anche un possibile ruolo per la blockchain.

Tra organizzazioni diverse potrebbe essere utile ancorare prove di autorizzazioni, accordi e ricevute a un registro condiviso. Terrei fuori dalla catena conversazioni e documenti riservati; sulla catena potrebbero finire le impronte crittografiche necessarie a verificare che certe registrazioni non siano state modificate.

La sceglierei dove quella verifica condivisa serve davvero. In altri casi un registro firmato sarebbe sufficiente. E in entrambi i casi rimane una distinzione concreta: una ricevuta può dimostrare cosa è stato registrato, ma il permesso di agire va controllato prima dell’azione. Anche un errore può essere registrato perfettamente.

Prima di concedere quei permessi vorrei poi avere un’anteprima. Una specie di simulatore dell’incarico: quali agenti verrebbero coinvolti, quali dati uscirebbero, quale budget sarebbe impegnato, in quali punti servirebbe il mio intervento.

Il piano reale potrebbe cambiare, certo. Ma quell’anteprima mi aiuterebbe a capire cosa sto autorizzando. E se durante il lavoro emerge la necessità di uscire dai limiti concordati, il sistema avrebbe un motivo preciso per tornare da me.

Lo stesso varrebbe per obiettivi che durano nel tempo. Potrei chiedere a un agente di seguire una questione per settimane, conservando stato, decisioni e questioni aperte. L’obiettivo continuerebbe a esistere anche quando chiudo la chat. I suoi permessi, invece, dovrebbero avere scadenze e condizioni proprie.

È questo insieme di possibilità che mi sta facendo guardare all’AI in modo diverso. Posso immaginare motori di ricerca per capacità, applicazioni che si compongono attorno a un incarico, comunità di agenti, gruppi temporanei e servizi che rendono verificabili le loro collaborazioni.

Con Spectre e il Governed Act Model sto cercando di lavorare su una parte di questo problema: il passaggio tra ciò che un’intelligenza propone e ciò che ha il potere di fare. Estendere quel ragionamento a una rete di soggetti diversi apre parecchie altre domande.

Una, per esempio, mi resta in testa: se tra qualche anno il mio assistente affiderà un lavoro a un agente che non conosco, ospitato su un sistema che non ho mai usato, quali prove mi serviranno per accettare quella collaborazione?

Mi piacerebbe arrivare al punto in cui posso farlo con la stessa naturalezza con cui oggi apro un link. Sapendo dove porta la mia autorizzazione, quanto può viaggiare e chi deve ancora rispondermi quando qualcosa rimane a metà.