Ti diamo il benvenuto alla Agents Week

La missione di Cloudflare è sempre stata quella di contribuire alla realizzazione di un Internet migliore. A volte questo significa creare per Internet così come esiste. A volte significa creare per Internet come sta per diventare. 

Oggi diamo il via alla Agents Week, dedicata alla creazione di Internet per quello che verrà dopo.

Il cloud, così come lo conosciamo, è stato un prodotto dell'ultimo grande cambiamento di paradigma tecnologico: gli smartphone.

Quando gli smartphone hanno messo Internet nelle tasche di tutti, non si sono limitati ad aggiungere utenti, ma hanno cambiato la natura di ciò che significava essere online. Sempre connesso, sempre in attesa di una risposta immediata. Le applicazioni dovevano gestire un ordine di grandezza superiore di utenti e l'infrastruttura su cui erano basate doveva evolversi.

L'approccio su cui il settore si è concentrato è stato semplice: più utenti, più copie della tua applicazione. Man mano che le applicazioni crescevano in complessità, i team le dividevano in frammenti più piccoli, i microservizi, in modo che ogni team potesse controllare il proprio destino. Ma il principio fondamentale è rimasto lo stesso: un numero finito di applicazioni, ciascuna al servizio di molti utenti. Scalare significava gestire più copie.

Kubernetes e i container sono diventati lo standard. Hanno semplificato l'avvio delle istanze, il bilanciamento del carico e la disattivazione di ciò che non era più necessario. Con questo modello one-to-many, una singola istanza poteva servire molti utenti e, anche se il numero di utenti cresceva fino a raggiungere i miliardi, il numero di cose che era necessario gestire rimaneva limitato.

Gli agenti compromettono questo modello.

A differenza di tutte le applicazioni precedenti, gli agenti sono one-to-one. Ogni agente è un'istanza univoca. Servire un utente, eseguire un'attività. Laddove un'applicazione tradizionale segue lo stesso percorso di esecuzione indipendentemente da chi la sta utilizzando, un agente richiede un proprio ambiente di esecuzione: un ambiente in cui l'LLM determina il percorso del codice, chiama gli strumenti in modo dinamico, regola il suo approccio e persiste fino al completamento dell'attività.

Pensa a questo come alla differenza tra un ristorante e uno chef personale. Un ristorante ha un menù, un insieme fisso di opzioni, e una cucina ottimizzata per sfornarle in base alle richieste. Questo vale per la maggior parte delle applicazioni oggi. Un agente è più simile a uno chef personale che chiede: cosa vuoi mangiare? Potrebbe aver bisogno di ingredienti, utensili o tecniche completamente diversi ogni volta. Non puoi gestire un servizio di chef personale con la stessa configurazione della cucina che useresti per un ristorante.

Nell'ultimo anno, abbiamo visto gli agenti decollare: non a caso, ad essere in testa sono gli agenti di codifica, dal momento che gli sviluppatori tendono ad essere early adopter. Il modo in cui la maggior parte degli agenti di codifica funziona oggi è il seguente: crea un container per fornire all'LLM ciò di cui ha bisogno, ovvero un file system, git, bash e la possibilità di eseguire file binari arbitrari.

Ma gli agenti di codifica sono solo l'inizio. Strumenti come Claude Cowork rendono già gli agenti accessibili agli utenti meno tecnici. Una volta che gli agenti vanno oltre gli sviluppatori e finiscono nelle mani di tutti (assistenti amministrativi, analisti di ricerca, agenti del servizio clienti, pianificatori personali), la complessità della scalabilità diventa rapidamente una questione di vitale importanza.

Se gli oltre 100 milioni di knowledge worker negli Stati Uniti utilizzassero ciascuno un assistente agentico con una simultaneità di circa il 15%, sarebbe necessaria una capacità di circa 24 milioni di sessioni simultanee. Con 25-50 utenti per CPU, si tratta di una cifra compresa tra 500.000 e 1 milione di CPU server, solo per gli Stati Uniti, con un agente per persona.

Ora immagina ogni persona che utilizza diversi agenti in parallelo. Ora immagina il resto del mondo con oltre 1 miliardo di knowledge worker. Non siamo solo a corto di risorse di elaborazione. Siamo lontani di ordini di grandezza.

Quindi come facciamo a colmare questo divario?

Otto anni fa abbiamo lanciato Workers: l'inizio della nostra piattaforma per sviluppatori e una scommessa sull'elaborazione containerless e serverless. La motivazione all'epoca era pratica: avevamo bisogno di elaborazione leggera senza avvii a freddo per i clienti che si affidavano a Cloudflare per la velocità. Basato su isolati V8 anziché su container, Workers si è rivelato un ordine di grandezza più efficiente: più veloce da avviare, più economico da eseguire e nativamente adatto al modello "spin up, execute, tear down".

Non ci aspettavamo che questo modello si adattasse così bene all'era degli agenti.

Laddove i container offrono a ogni agente una cucina commerciale completa, ovvero elettrodomestici fissi, frigoriferi, tutto il necessario, che l'agente ne abbia bisogno o meno, gli isolati, d'altra parte, danno allo chef personale esattamente lo spazio sul bancone, il fornello e il coltello di cui ha bisogno per un particolare pasto. Sottoposto a provisioning in millisecondi. Pulito non appena il piatto viene servito.

In un mondo in cui dobbiamo supportare non migliaia di applicazioni di lunga durata, ma miliardi di ambienti di esecuzione temporanei e monouso, gli isolati sono la primitiva giusta. 

Ognuno inizia in millisecondi. Ognuno è in una sandbox protetta. E puoi eseguirne ordini di grandezza in più sullo stesso hardware rispetto ai container.

Solo poche settimane fa, ci siamo spinti oltre con la versione versione beta aperta di Dynamic Workers: ambienti di esecuzione creati in fase di runtime, on demand. Un isolato richiede alcuni millisecondi per avviarsi e utilizza pochi megabyte di memoria. È circa 100 volte più veloce e fino a 100 volte più efficiente in termini di memoria rispetto a un container. 

Puoi avviarne uno nuovo per ogni singola richiesta, eseguire un frammento di codice ed eliminarlo, su una scala di milioni al secondo.

Affinché gli agenti vadano oltre i primi utenti e siano nelle mani di tutti, devono anche essere economicamente vantaggiosi. Gestire ogni agente nel proprio container è così costoso che gli strumenti agentici oggi sono per lo più limitati ad assistenti di codifica per ingegneri che possono giustificare il costo. Gli isolati vengono eseguiti in ordini di grandezza in modo più efficiente, rendendo il modello economico per unità praticabile alla scala richiesta dagli agenti.

Sebbene sia fondamentale gettare le basi per il futuro, il percorso è ancora lungo. In ogni cambio di paradigma, c’è sempre una fase in cui tentiamo di forzare le nuove innovazioni negli schemi del passato. Le prime automobili erano chiamate "carrozze senza cavalli." I primi siti web erano opuscoli digitali. Le prime app per dispositivi mobili erano interfacce utente desktop rimpicciolite. Attualmente, siamo ancora in quella fase per gli agenti.

Si vede ovunque. 

Stiamo costringendo gli agenti a usare browser headless per navigare in siti web nati per l'interazione umana, quando avrebbero bisogno di protocolli strutturati come MCP per l'individuazione e l'invocazione diretta dei servizi. 

Molti dei primi server MCP non sono che semplici wrapper per API REST preesistenti (stesse operazioni CRUD, solo con un nuovo protocollo) nonostante gli LLM siano decisamente più portati per la scrittura di codice che per l'esecuzione sequenziale di chiamate strumentali. 

Utilizziamo CAPTCHA e fingerprinting comportamentale per verificare l'identità dietro ogni richiesta, ignorando che sempre più spesso si tratti di un agente. La domanda cruciale non è più "Sei umano?", ma "Che tipo di agente sei, chi ti ha autorizzato e quali sono i tuoi permessi?"

Stiamo creando container completi per gli agenti che devono solo effettuare alcune chiamate API e restituire un risultato.

Questi sono solo alcuni esempi, ma niente di tutto questo è sorprendente. Ecco come appaiono le transizioni.

Internet è sempre una via di mezzo tra due epoche. IPv6 è oggettivamente migliore di IPv4, ma l'eliminazione del supporto IPv4 interromperebbe metà di Internet. HTTP/2 e HTTP/3 coesistono. TLS 1.2 non ha ancora completamente ceduto il passo a 1.3. La tecnologia migliore esiste, quella precedente persiste, e il compito dell'infrastruttura è quello di collegarle entrambe.

Cloudflare si è sempre occupata di colmare queste transizioni. Il passaggio agli agenti non fa eccezione.

Gli agenti di codifica hanno davvero bisogno di container: un file system, git, bash, un'esecuzione binaria arbitraria. E la situazione non è destinata a cambiare presto. Questa settimana i nostri ambienti sandbox basati su container diventano ufficialmente disponibili (GA), a conferma del nostro impegno nel renderli lo standard di riferimento per il settore. Stiamo potenziando le capacità di rendering del browser per gli agenti: siamo consapevoli che esisterà una vasta gamma di servizi legacy non ancora compatibili con MCP con cui gli agenti dovranno comunque interagire. Queste non sono soluzioni temporanee: fanno parte di una piattaforma completa.

Ma stiamo anche realizzando ciò che verrà dopo: gli isolati, i protocolli e i modelli di identità di cui gli agenti hanno effettivamente bisogno. Il nostro compito è assicurarci che non si debba scegliere tra ciò che funziona oggi e quello che è giusto per domani.

Se gli agenti dovranno gestire le nostre attività professionali e personali, dalla lettura delle e-mail alla gestione del codice o dei servizi finanziari, la sicurezza deve essere parte integrante del modello di esecuzione, non un elemento aggiunto a posteriori.

I CISO sono stati i primi ad affrontare questo problema. I guadagni di produttività derivanti dal mettere gli agenti nelle mani di tutti sono reali, ma oggi la maggior parte delle distribuzioni di agenti è irta di ostacoli: inoculazione di prompt, esfiltrazione dei dati, accesso alle API non autorizzato, utilizzo poco chiaro degli strumenti. 

Un agente di sviluppo per il "vibe-coding" deve accedere a repository e pipeline di distribuzione. L'agente del servizio clienti di un'azienda deve accedere alle API interne e ai dati degli utenti. In entrambi i casi, proteggere l'ambiente oggi significa mettere insieme credenziali, criteri di rete e controlli degli accessi che non sono mai stati progettati per il software autonomo.

Cloudflare ha sviluppato due piattaforme in parallelo: la nostra piattaforma per sviluppatori, per le persone che creano applicazioni, e la nostra piattaforma Zero Trust, per le organizzazioni che devono proteggere l'accesso. Per un po', hanno servito un pubblico distinto. 

Ma "come posso creare questo agente?" e "come posso assicurarmi che sia sicuro?" sono sempre più la stessa domanda. Stiamo integrando queste piattaforme affinché tutto ciò sia nativo nel modello di esecuzione degli agenti, anziché rappresentare uno strato separato da aggiungere in un secondo momento.

C'è un'altra dimensione nell'era degli agenti che va oltre l'elaborazione e la sicurezza: il modello economico e la governance.

Quando gli agenti interagiscono con Internet per nostro conto, leggendo articoli, consumando API, accedendo ai servizi, deve esserci un modo per le persone e le organizzazioni che creano tali contenuti ed eseguono tali servizi per stabilire condizioni e ricevere un compenso. Il modello economico del web odierno gravita attorno all'attenzione umana, tra annunci pubblicitari e sistemi di abbonamento. 

Gli agenti, tuttavia, operano in modo diverso: la loro "attenzione" non è un bene monetizzabile in modo tradizionale. Non vedono gli annunci. Non fanno clic sui banner dei cookie.

Se vogliamo un Internet in cui gli agenti possano operare liberamente e in cui editori, autori di contenuti e service provider siano equamente compensati, abbiamo bisogno di una nuova infrastruttura. Stiamo realizzando strumenti che consentono agli editori e ai proprietari di contenuti di impostare e applicare facilmente criteri su come gli agenti interagiscono con i loro contenuti.

Creare un'Internet di valore significa guardare oltre chi costruisce gli strumenti, mettendo al centro le persone che, con creatività e impegno, rendono la rete degno di essere utilizzata. Questo paradigma non cambia nell'era degli agenti. Diventa più importante.

Il nostro obiettivo è sempre stato fornire una piattaforma che "funzioni e basta": un ecosistema totale che supporti ogni fase, dalla sperimentazione al prodotto minimo funzionante, fino alla gestione di milioni di utenti. Ma fornire le primitive è solo una parte dell'equazione. Una grande piattaforma deve avere una visione d'insieme: deve garantire che ogni componente interagisca armoniosamente e si integri perfettamente nel flusso di sviluppo.

Siamo di fronte a un'evoluzione. Prima si trattava solo di ottimizzare l'esperienza umana, rendendo facile per gli sviluppatori costruire, testare e mettere online i propri progetti. Sempre più spesso, la sfida consiste nel mettere gli agenti in condizione di supportare le persone, garantendo che la piattaforma risponda alle esigenze non solo di chi crea gli agenti, ma degli agenti stessi. Un agente può trovare le best practice più aggiornate? Con quanta agilità può scoprire e richiamare gli strumenti e le CLI di cui ha bisogno? Come può passare facilmente dalla scrittura del codice alla sua distribuzione?

Questa settimana introdurremo miglioramenti su entrambi i fronti, rendendo Cloudflare una piattaforma superiore sia per le persone che vi sviluppano, sia per gli agenti che vi operano.

Costruire per il futuro non è qualcosa che possiamo fare da soli. Ogni grande transizione di Internet, da HTTP/1.1 a HTTP/2 e HTTP/3, da TLS 1.2 a 1.3, ha richiesto al settore di convergere su standard condivisi. Il passaggio agli agenti non sarà diverso.

Cloudflare ha una lunga storia nel contribuire e promuovere gli standard che fanno funzionare Internet. Siamo profondamente coinvolti nell'IETF da oltre un decennio, contribuendo a sviluppare e distribuire protocolli come QUIC, TLS 1.3 e Encrypted Client Hello. Siamo stati membri fondatori di WinterTC, il comitato tecnico ECMA per l'interoperabilità del runtime JavaScript. Abbiamo reso open source il runtime di Workers, perché riteniamo che le fondamenta debbano essere aperte.

Stiamo adottando lo stesso approccio all'era degli agenti. Siamo orgogliosi di far parte della Linux Foundation e dell'AAIF: il nostro obiettivo è sostenere e promuovere standard come l'MCP, pilastri fondamentali per l'evoluzione dell'ecosistema degli agenti. Da quando Anthropic ha introdotto MCP, abbiamo lavorato a stretto contatto con loro per creare l'infrastruttura per i server MCP remoti, abbiamo reso open source le nostre implementazioni e abbiamo investito per rendere il protocollo pratico su larga scala. 

L'anno scorso, insieme a Coinbase, abbiamo co-fondato la x402 Foundation, uno standard aperto e neutrale che fa rivivere il codice di stato HTTP 402 a lungo inattivo per offrire agli agenti un modo nativo per pagare i servizi e i contenuti che consumano. 

Identità dell'agente, autorizzazione, pagamento, sicurezza: tutti questi elementi necessitano di standard aperti che nessuna singola azienda può definire da sola.

Questa settimana faremo annunci su ogni dimensione dello stack di agenti: elaborazione, connettività, sicurezza, identità, modello economico ed esperienza degli sviluppatori.

Internet non è stato creato per l'IA. Il cloud non è stato creato per gli agenti. Cloudflare si è sempre dedicata alla realizzazione di un Internet migliore, ma il concetto stesso di "migliore" si evolve insieme a ogni nuova era. Questa è l'era degli agenti. Seguici durante questa settimana: ti mostreremo concretamente come stiamo plasmando questo nuovo futuro.