Cloudflare ha pubblicato @cloudflare/computer, un runtime per agenti che sceglie dinamicamente fra isolati veloci e container Linux completi, e ha aperto la “Agents Week”: una serie di post su come l’infrastruttura cloud deve cambiare quando i client sono agenti autonomi, non browser umani.

Perché ti riguarda. Se stai schierando agenti in produzione, dove e come girano conta quanto il modello che scegli. Un agente che deve navigare il web ha bisogno di un browser in un container Linux completo. Uno che elabora testo veloce sta meglio in un isolato, un ambiente di esecuzione leggero che parte in millisecondi. Oggi gestisci questa scelta a mano, costruendo l’infrastruttura attorno. @cloudflare/computer mette un runtime in mezzo: dichiari cosa ti serve e lui instrada nell’ambiente giusto.

Questo si inserisce in un filo che stiamo seguendo. Come raccontavamo a luglio, il protocollo MCP è diventato senza stato per scalare meglio. Ora Cloudflare fa la stessa cosa al livello di esecuzione: l’ambiente di runtime diventa orchestrabile, non fisso.

Il secondo post della settimana riguarda l’inferenza: come servire Kimi e GLM su GPU senza esaurire la memoria, con quantizzazione della KV cache (la memoria dove il modello tiene il contesto della conversazione) e compressione dei pesi. Dettagli che pesano sul costo di chi fa girare agenti a volume.

Se vuoi guardarci. I post della Agents Week e la documentazione di @cloudflare/computer sono sul blog di Cloudflare.

Nel dettaglio

Cloudflare Workers esiste dal 2017 come piattaforma per girare codice ai margini della rete. Il modello è l’isolato: un ambiente di esecuzione sandboxed che parte in millisecondi e consuma pochissima memoria, perché non avvia un sistema operativo completo. È perfetto per rispondere a una richiesta HTTP, trasformare un JSON, servire una pagina.

Gli agenti hanno un problema diverso. Un agente che naviga il web ha bisogno di un browser, e un browser ha bisogno di un sistema operativo. Un agente che scrive file e li elabora ha bisogno di un filesystem reale. Gli isolati non bastano. I container Linux completi risolvono, ma partono in secondi invece di millisecondi e consumano più risorse. Fino a oggi, chi schierava agenti su Cloudflare doveva scegliere una delle due vie e costruire tutto attorno a quella scelta.

@cloudflare/computer mette un runtime in mezzo che decide da solo. L’agente dichiara cosa gli serve (un browser, un filesystem, accesso alla rete) e il runtime lo instrada nell’ambiente giusto. Se il task è leggero, va in isolato. Se serve un browser, va in container. La transizione è trasparente all’agente, che vede sempre “un computer” come ambiente di esecuzione.

La Agents Week espande il discorso. Cloudflare argomenta che l’infrastruttura cloud è stata disegnata per un mondo dove a fare richieste sono umani con browser: rate limiting calibrato sul traffico umano, storage pensato per sessioni utente, sicurezza basata su cookie e CORS. Gli agenti rompono queste assunzioni. Fanno richieste a velocità elevate, mantengono stato per ore, accedono a risorse in modi che i pattern di sicurezza attuali non coprono. Serve un insieme nuovo di primitive.

Il secondo post della settimana scende su un livello ancora più basso: come servire modelli frontier come Kimi e GLM su GPU senza esaurire la memoria. Cloudflare applica quantizzazione alla KV cache (dove il modello tiene il contesto della conversazione) e compressione ai pesi del modello, con controlli di integrità per verificare che la compressione non abbia corrotto i risultati. Per chi fa girare agenti che consumano molti token, il costo dell’inferenza si decide anche qui, non solo sul cartellino del prezzo del modello.

I limiti di quello che sappiamo. I post del blog descrivono l’architettura, ma i dettagli sul pricing, sugli SLA e sulla disponibilità generale di @cloudflare/computer non sono ancora chiari dal materiale pubblicato. La Agents Week è in corso: altri post potrebbero aggiungere informazioni operative nei prossimi giorni. Per chi valuta la piattaforma per agenti in produzione, il runtime è interessante sul piano concettuale ma va collaudato sul proprio carico reale prima di prendere una decisione.