Cloudflare OS Managed Agent Workspace passa dall’open source a un servizio con lista d’attesa

Cloudflare ha aperto una lista d’attesa per il suo primo spazio di lavoro per agenti Cloudflare OS completamente gestito, appena un mese dopo aver rilasciato la piattaforma sottostante in open source. Il cambiamento trasforma Cloudflare OS da un progetto che le imprese devono gestire autonomamente in un servizio che Cloudflare intende gestire per loro.

Potrebbe sembrare una tradizionale edizione ospitata, ma Cloudflare punta a un ruolo più ampio. Vuole offrire a ogni dipendente uno spazio di lavoro persistente che comprenda le procedure aziendali e possa agire sui sistemi autorizzati. Lo spazio di lavoro può cercare informazioni, creare documenti, modificare codice e trasformare attività ripetute in applicazioni.

La pressione ricade su Microsoft, Google e altri fornitori cloud che già vendono piattaforme di agenti enterprise. I loro prodotti beneficiano di posizioni consolidate nelle suite per ufficio e negli account cloud. Cloudflare scommette sul fatto che identità, controlli di rete, instradamento dei modelli ed esecuzione isolata possano diventare una base altrettanto importante per gli agenti sul posto di lavoro.

Cloudflare OS Managed Agent Workspace entra nella fase della lista d’attesa

Cloudflare non sta annunciando la disponibilità generale. Sta testando se le aziende desiderano la piattaforma open source senza l’onere operativo.

Cloudflare ha annunciato l’opzione gestita il 1 ottobre 2026. Le organizzazioni possono iscriversi a una lista d’attesa, ma l’azienda non ha fornito una data di lancio, impegni sui livelli di servizio, un elenco delle regioni disponibili o condizioni commerciali.

La distinzione è importante perché la versione open source è già disponibile. Le aziende possono distribuirla nei propri account Cloudflare, personalizzarne l’interfaccia e collegarla alle risorse interne. Devono però anche configurare, gestire, aggiornare e proteggere tale deployment.

Cloudflare propone ora una diversa ripartizione delle responsabilità. I clienti sceglierebbero gli utenti autorizzati, il contesto aziendale, le competenze organizzative, i sistemi collegati, un dominio personalizzato e le policy di accesso pertinenti. Cloudflare gestirebbe il restante lavoro di deployment e operatività.

Secondo l’annuncio del servizio gestito, le organizzazioni selezioneranno anche l’AI Gateway utilizzato dal proprio deployment. AI Gateway si colloca tra lo spazio di lavoro e i fornitori di modelli, dove può applicare controlli di instradamento, logging e policy.

Cloudflare afferma che migliaia di organizzazioni hanno iniziato a usare Cloudflare OS nel mese successivo al suo rilascio open source. Questa cifra proviene da Cloudflare e non ha ricevuto verifiche indipendenti. L’azienda non ha comunicato quanti deployment siano attivi, sperimentali o utilizzati nell’intera organizzazione.

Tuttavia, la lista d’attesa riflette un insegnamento concreto emerso dal lancio open source. Pubblicare il codice rimuove le barriere di licensing e personalizzazione, ma non elimina il lavoro di deployment. Un’impresa deve comunque stabilire regole di identità, collegare sistemi, proteggere le credenziali, testare gli aggiornamenti e indagare sui malfunzionamenti.

Il servizio gestito è la risposta di Cloudflare a questo divario di adozione. Offre alle imprese personalizzazione senza richiedere a ogni cliente di costruire un processo operativo dedicato attorno alla piattaforma.

Il tempismo rivela anche il mercato a cui Cloudflare punta. Cloudflare OS non viene posizionato soltanto come kit di sviluppo per agenti destinato ai team software. L’azienda descrive uno spazio di lavoro per dipendenti di vendite, finanza, supporto, operazioni e ingegneria.

Un incontro con un cliente illustra la portata. Un dipendente potrebbe chiedere a un agente di esaminare i record degli account, analizzare i ticket di supporto, valutare l’utilizzo del prodotto e preparare una presentazione. L’attività attraversa diversi sistemi e produce un risultato di lavoro modificabile, anziché una breve risposta in chat.

Cloudflare ha inoltre aggiornato la piattaforma nel suo primo mese. Ora gli utenti possono collegare repository GitHub e chiedere agli agenti di ispezionare il codice, modificare file, creare commit o aprire pull request. Queste funzioni portano lo sviluppo software in un prodotto inizialmente presentato attorno a un più ampio lavoro basato sulla conoscenza.

Anche l’integrazione con Google Workspace si è ampliata. Cloudflare afferma che gli agenti possono cercare nelle conversazioni di Gmail, creare bozze, inviare messaggi e usare risorse Drive collegate. Gli amministratori possono esporre un intero Drive, una cartella o un singolo documento.

Lo spazio di lavoro può esportare documenti e dati come file Excel, CSV, PDF, Markdown o HTML. Le esportazioni Word e PowerPoint sono previste, ma non erano disponibili quando Cloudflare ha pubblicato l’annuncio.

Queste aggiunte ampliano il lavoro che il prodotto può indirizzare. Ampliano però anche la sua superficie di rischio. Un agente che può leggere email, accedere ai file, modificare codice e inviare messaggi richiede controlli più rigorosi di un chatbot che si limita a redigere testo.

Questa tensione conduce direttamente alla proposta principale di Cloudflare. L’azienda vende operazioni gestite, ma la sua tesi più ampia riguarda l’accesso governato ai dati enterprise.

Il vero prodotto è un livello di esecuzione governato

Cloudflare OS combina uno spazio di lavoro rivolto ai dipendenti con un’infrastruttura che controlla ciò che gli agenti possono vedere, eseguire, conservare e condividere.

Uno spazio di lavoro contiene conversazioni, file, output, autorizzazioni, attività ed eventi programmati. A differenza di una normale sessione chat, può conservare lo stato dopo che l’utente chiude il browser. Questa persistenza supporta progetti che proseguono attraverso più sessioni.

L’architettura di riferimento di Cloudflare colloca Workers e Agents SDK nel livello di orchestrazione. Durable Objects mantengono lo stato, mentre Dynamic Workers e container sandbox eseguono attività che richiedono codice.

AI Gateway controlla l’accesso ai modelli approvati. I portali Model Context Protocol collegano lo spazio di lavoro agli strumenti enterprise. MCP è un’interfaccia standard attraverso la quale gli agenti scoprono gli strumenti disponibili e ne invocano le operazioni.

L’architettura mantiene il modello separato dalle credenziali e dall’applicazione delle policy. Questa separazione è importante perché un modello linguistico non dovrebbe ricevere una chiave API con privilegi estesi ogni volta che necessita di dati aziendali.

Cloudflare utilizza servizi denominati Gatekeepers tra Cloudflare OS e i sistemi esterni. Ogni Gatekeeper comprende il servizio di destinazione, le risorse disponibili, le operazioni consentite e le relative policy organizzative.

Un GitHub Gatekeeper potrebbe esporre un solo repository senza esporre un intero account. Potrebbe consentire l’accesso alle issue trattenendo il codice sorgente. Potrebbe inoltre richiedere l’approvazione umana prima che un agente unisca una pull request.

L’agente vede un’interfaccia di programmazione limitata anziché la credenziale sottostante. Cloudflare afferma che le credenziali restano isolate dal codice generato. Anche il codice lato server viene eseguito con l’accesso alla rete in uscita disabilitato, salvo che un amministratore fornisca una capacità approvata.

Questo modello parte senza alcun accesso. Un agente o un’applicazione generata deve ricevere l’autorizzazione per ogni risorsa utilizzata. Tale struttura segue il principio del privilegio minimo, che limita un’identità alle risorse necessarie per il compito assegnato.

Cloudflare si spinge oltre tracciando le risorse osservate da un agente. Se un agente legge un dataset con restrizioni e crea una dashboard, la dashboard mantiene una relazione con quella fonte.

Quando un altro dipendente apre l’output, i Gatekeepers possono verificare se tale dipendente è autorizzato ad accedere alle risorse osservate. L’obiettivo è impedire che gli output generati aggirino le autorizzazioni associate ai dati originali.

Questo problema è diventato centrale per gli agenti enterprise. L’autorizzazione tradizionale risponde alla domanda se un utente possa aprire un file o interrogare un’applicazione. I sistemi agentici possono combinare informazioni provenienti da varie risorse e produrre un nuovo artefatto.

Il nuovo artefatto potrebbe contenere informazioni sensibili senza mantenere i controlli di accesso del sistema originario. Un riepilogo, un grafico, un’applicazione o una bozza di email possono diventare un percorso indiretto attorno ai confini dei dati.

L’approccio di Cloudflare tratta la provenienza delle informazioni come parte dell’autorizzazione. La piattaforma tenta di ricordare ciò che un agente ha visto, quindi usa questa cronologia per stabilire chi può accedere al suo lavoro.

Questo va oltre un framework per connettori. È un tentativo di governare i dati dopo che un agente li ha trasformati.

Il post di lancio open source spiega perché Cloudflare ha ricostruito la piattaforma attorno a questo requisito. La sua prima versione interna supportava spazi di lavoro privati, ma la collaborazione ha esposto rischi legati ad applicazioni e output condivisi.

Cloudflare ha concluso che l’accesso a uno strumento MCP non rivelava tutte le risorse sottostanti osservate attraverso quello strumento. Ha quindi aggiunto controlli che operano al di sotto dell’interfaccia dello spazio di lavoro.

Il design separa inoltre il lavoro deterministico dall’inferenza del modello. Un agente può trasformare una procedura ricorrente in codice, quindi usare un modello soltanto dove è necessario il giudizio.

Si consideri una dashboard di supporto. Il software può recuperare i conteggi dei ticket, raggruppare i record e generare grafici senza chiedere a un modello di ripetere tali passaggi. Un modello può restare disponibile per classificare casi insoliti o redigere risposte suggerite.

Questa separazione può ridurre l’inferenza non necessaria e creare flussi di lavoro più prevedibili. Rende inoltre l’output più facile da ispezionare perché il codice standard gestisce le operazioni ripetibili.

Cloudflare afferma che i propri team hanno usato questo schema per il reporting interno sui ticket. Un agente ha creato un’applicazione collegata ai dati dei ticket, mentre i dipendenti hanno mantenuto l’autorità di revisione sulle risposte redatte.

Resta un esempio riportato dall’azienda, non uno studio indipendente sulle prestazioni. Eppure illustra la progressione prevista dalla piattaforma: conversazione, flusso di lavoro riutilizzabile e applicazione persistente.

Il repository sorgente dell’azienda contiene inoltre un chiaro avviso di accesso anticipato. Descrive la versione due come una riscrittura completa con alcune asperità ancora da risolvere. Tale avviso dovrebbe orientare qualsiasi valutazione del servizio gestito.

Un deployment ospitato può semplificare le operazioni, ma non può rendere automaticamente un software incompleto adatto a flussi di lavoro critici. Gli acquirenti devono distinguere la gestione dell’infrastruttura dalla maturità dell’applicazione.

Microsoft e Google possiedono le applicazioni, mentre Cloudflare punta al piano di controllo

La sfida principale di Cloudflare non è costruire un altro agente. È superare rivali che controllano già dove lavorano i dipendenti.

Microsoft può collocare gli agenti all’interno di Microsoft 365, Teams, SharePoint, Dynamics e Power Platform. Google può collegare gli agenti a Workspace, Cloud, Drive, Gmail e alla ricerca organizzativa.

Queste posizioni riducono l’attrito nell’adozione. I dipendenti possono incontrare gli agenti nelle applicazioni familiari, mentre gli amministratori possono riutilizzare i controlli esistenti su identità, conformità e dati.

Il piano per gli agenti enterprise di Microsoft comprende strumenti low-code, runtime gestiti, connettori e servizi per sviluppatori. Copilot Studio supporta i team aziendali, mentre Microsoft Foundry si rivolge agli sviluppatori che costruiscono sistemi più personalizzati.

Google segue una strategia di piattaforma simile. I suoi prodotti enterprise combinano interfacce per dipendenti, accesso ai modelli, ricerca, connettori, creazione di agenti e amministrazione centralizzata.

Cloudflare non possiede una suite di produttività di primo piano. Non può presumere che i dipendenti trascorrano già la giornata in un editor di documenti, una casella di posta, un foglio di calcolo o un’applicazione di collaborazione Cloudflare.

Invece, sta posizionando Cloudflare OS al di sopra di questi sistemi. Il workspace si collega agli strumenti esistenti, mentre Cloudflare fornisce esecuzione, networking, applicazione dell'identità e governance dei modelli.

Si tratta di una strategia di control plane. Un control plane definisce le policy e coordina le risorse, mentre le applicazioni collegate restano i sistemi di riferimento.

L'approccio crea potenziali vantaggi per gli ambienti misti. Molte organizzazioni usano applicazioni Microsoft, servizi Google, GitHub, Salesforce, database interni e diversi provider di modelli. Un workspace neutrale può teoricamente superare questi confini.

Cloudflare OS consente inoltre ai clienti di scegliere i modelli a cui accedere tramite AI Gateway. Questo design evita di vincolare l'interfaccia del workspace a una sola famiglia di modelli, anche se le integrazioni disponibili e i termini del servizio gestito restano poco chiari.

L'architettura è coerente con la posizione già consolidata di Cloudflare nelle reti aziendali e nella sicurezza delle applicazioni. I clienti potrebbero già usare Cloudflare Access per l'accesso alle applicazioni basato sull'identità o AI Gateway per i controlli sul traffico dei modelli.

Per queste organizzazioni, Cloudflare OS può estendere un livello di policy consolidato agli agenti dei dipendenti. L'argomentazione commerciale è più solida quando il cliente ha già configurato i servizi circostanti.

Tuttavia, la neutralità ha un costo. Microsoft e Google possono offrire comportamenti nativi più profondi all'interno delle proprie suite. Cloudflare deve riprodurre o mediare tali azioni tramite Gatekeepers e API esterne.

Ogni integrazione aggiunge lavoro di manutenzione. Il comportamento delle API cambia, i flussi di autenticazione evolvono e i permessi aziendali variano tra tenant. Cloudflare deve mantenere affidabili queste connessioni se vuole che il prodotto gestito sembri un unico workspace.

La piattaforma deve inoltre competere con l'infrastruttura per agenti gestita dai provider cloud. Il runtime AgentCore di Amazon gestisce scalabilità, gestione delle sessioni, infrastruttura e isolamento per gli agenti distribuiti.

AgentCore è più direttamente incentrato sull'esecuzione di applicazioni agentiche, mentre Cloudflare OS include un'interfaccia per i dipendenti e strumenti per produrre lavoro persistente. I prodotti si sovrappongono nel livello di esecuzione gestita, anche quando le loro esperienze utente differiscono.

Questa concorrenza mostra come il mercato si stia dividendo in più livelli. I provider di modelli forniscono sistemi di ragionamento. Le piattaforme cloud eseguono gli agenti. Le suite di produttività offrono superfici utente. I servizi di integrazione collegano gli strumenti aziendali.

Cloudflare sta cercando di riunire diversi livelli senza possedere le applicazioni sottostanti. La sua differenziazione dipende dal fatto che governance ed esecuzione tra sistemi superino o meno la comodità degli agenti nativi delle suite.

Questo rende decisivo il contesto di approvvigionamento. Un'azienda standardizzata su Microsoft 365 potrebbe preferire il proprio ambiente amministrativo esistente. Un'organizzazione con sistemi eterogenei potrebbe attribuire maggiore valore a un workspace neutrale rispetto ai modelli e alle applicazioni.

Gli sviluppatori affrontano una scelta simile. Possono creare agenti separati per singole mansioni oppure fornire ai dipendenti un workspace condiviso che possa creare strumenti quando emergono nuove esigenze.

Il modello di workspace può ridurre la frammentazione. I dipendenti mantengono una sola cronologia degli agenti, un unico insieme di capacità approvate e una sola libreria di competenze organizzative. I team possono condividere procedure anziché ricreare prompt per ogni attività.

Può anche concentrare il rischio. Un unico workspace collegato a molti sistemi diventa un importante confine di sicurezza. Un errore di configurazione o un'integrazione difettosa potrebbe influire su diversi workflow anziché su un singolo agente circoscritto.

Questo compromesso spiega perché l'edizione gestita è importante. Cloudflare sta chiedendo ai clienti di affidarle il funzionamento di un workspace che attraversa sistemi sensibili, non semplicemente l'hosting di un'interfaccia web.

Le operazioni gestite non risolvono il problema della fiducia

La waitlist elimina parte del lavoro di distribuzione, ma Cloudflare non ha ancora fornito prove sufficienti per risolvere le questioni relative a sicurezza, affidabilità e adozione.

La prima incertezza riguarda la maturità del prodotto. Cloudflare OS rimane un software open source in accesso anticipato e il servizio gestito non ha una data di disponibilità annunciata.

Una waitlist può misurare l'interesse prima che Cloudflare impegni capacità e risorse di supporto. Significa anche che gli acquirenti non possono ancora valutare un contratto definitivo, un confine del servizio o un modello operativo.

Cloudflare non ha pubblicato dettagli del servizio gestito riguardanti residenza dei dati, policy di backup, risposta agli incidenti, calendari degli aggiornamenti, obiettivi di ripristino o integrazioni supportate. Questi dettagli conteranno più della comodità di installazione.

La seconda incertezza riguarda l'accuratezza delle autorizzazioni. Il monitoraggio delle risorse osservate è una risposta ponderata alla fuga di dati, ma i permessi aziendali reali sono complessi.

Le regole di accesso possono dipendere da ruolo, posizione, progetto, stato di sicurezza del dispositivo, campi dei record, vincoli legali o eccezioni temporanee. Un Gatekeeper deve interpretare correttamente questi vincoli sia durante la lettura sia durante la condivisione.

Le applicazioni generate aggiungono un ulteriore livello. Un'app può conservare dati, trasformare campi, memorizzare risultati nella cache e accettare input da più utenti. L'applicazione delle policy deve sopravvivere a tutte queste transizioni.

Cloudflare afferma che i Gatekeepers registrano le osservazioni e verificano l'accesso quando il lavoro viene condiviso. Test indipendenti non hanno stabilito come questo modello gestisca ogni trasformazione, revoca o inferenza indiretta.

La revoca merita particolare attenzione. Se un dipendente perde l'accesso a una fonte dopo che un agente ha creato un output, il sistema deve decidere se quel dipendente possa conservare il materiale derivato.

Gli amministratori avranno inoltre bisogno di record di audit comprensibili. Un log che mostra che un agente ha chiamato uno strumento è insufficiente se gli investigatori non possono determinare quali record abbiano influenzato un output.

La terza incertezza riguarda il codice generato. Cloudflare OS consente agli agenti di scrivere ed eseguire software all'interno di ambienti isolati. L'isolamento riduce l'esposizione, ma il codice generato può comunque contenere errori logici.

Un workflow potrebbe selezionare i record sbagliati, applicare erroneamente un filtro, inviare un report incompleto o compiere un'azione non intenzionale. Questi errori possono verificarsi senza evadere dalla sandbox.

I controlli di approvazione possono limitare gli effetti collaterali dannosi. Possono anche creare un carico di revisione costante se ogni azione significativa richiede la conferma umana.

Le organizzazioni avranno bisogno di diversi livelli di autonomia per compiti diversi. Leggere un documento approvato presenta meno rischi che inviare email, modificare codice sorgente o aggiornare un record cliente.

La quarta incertezza riguarda la profondità delle integrazioni. Cloudflare mette in evidenza GitHub e Google Workspace, ma la maggior parte delle aziende si affida a molti altri sistemi. Un workspace gestito diventa utile solo quando i suoi connettori corrispondono al lavoro effettivo.

Collegare un sistema non basta. L'integrazione deve comprendere permessi granulari, mantenere un'autenticazione stabile, gestire gli errori ed esporre azioni in una forma che gli agenti possano usare in sicurezza.

La quinta incertezza riguarda l'adozione. Dare un agente a ogni dipendente non garantisce che i dipendenti riprogettino il proprio lavoro attorno a esso.

I lavoratori hanno bisogno di competenze organizzative affidabili, esempi chiari, pratiche di revisione e supporto. I team devono inoltre concordare quali output richiedono verifica.

Cloudflare afferma che migliaia dei suoi dipendenti utilizzano la piattaforma interna e che i team hanno creato migliaia di strumenti. Queste cifre dimostrano attività interna, ma restano stime aziendali provenienti dal suo stesso ambiente.

I dipendenti Cloudflare hanno inoltre un accesso insolito alle persone che costruiscono il prodotto. I clienti esterni potrebbero trovarsi ad affrontare condizioni diverse di onboarding, supporto, conformità e gestione del cambiamento.

Una distribuzione gestita può ridurre il lavoro infrastrutturale. Non può curare la conoscenza aziendale, risolvere procedure poco chiare o decidere quali workflow meritino l'automazione.

Le organizzazioni dovrebbero considerare questa preparazione come un progetto di gestione della conoscenza. Una knowledge base di team affidabile necessita di responsabilità chiare, regole di accesso, materiali aggiornati e processi per correggere indicazioni obsolete.

Cloudflare OS si basa su contesto curato e competenze riutilizzabili. Se questi input entrano in conflitto o diventano obsoleti, l'agente può eseguire la procedura sbagliata in modo più efficiente.

Il servizio gestito deve quindi dimostrare due cose. Cloudflare deve gestire in modo affidabile la piattaforma tecnica, mentre i clienti devono mantenere il livello organizzativo che fornisce agli agenti istruzioni utili.

Nessuna delle due responsabilità scompare dietro pochi clic di distribuzione.

Tre segnali mostreranno se Cloudflare OS può diventare infrastruttura aziendale

La fase successiva dipende dai dettagli del servizio, dalle prove in produzione e dalla dimostrazione che il modello di governance di Cloudflare funziona al di fuori della sua organizzazione.

Il primo segnale è un rilascio definito del servizio gestito. Cloudflare deve pubblicare disponibilità, regioni supportate, copertura delle integrazioni, controlli amministrativi e confini di responsabilità.

Un rilascio privo di questi dettagli indebolirebbe l'argomentazione infrastrutturale. Un modello operativo documentato la rafforzerebbe, soprattutto per i team di sicurezza e conformità che valutano un utilizzo a lungo termine.

Gli acquirenti dovrebbero cercare risposte chiare su collocazione dei dati, instradamento dei modelli, log, backup, gestione degli incidenti, aggiornamenti e isolamento dei tenant. Dovrebbero inoltre esaminare in che modo le distribuzioni gestite differiscano dalle installazioni gestite dal cliente.

Il secondo segnale è l'adozione indipendente in produzione. L'affermazione di Cloudflare sulle migliaia di organizzazioni descrive un interesse iniziale, ma non rivela un utilizzo continuativo.

Prove più solide includerebbero clienti nominati, workflow definiti, scala di distribuzione, feedback degli amministratori e tassi di errore misurati. I case study dovrebbero spiegare come le organizzazioni hanno gestito permessi e revisione umana.

La profondità dell'utilizzo conta più delle dimensioni della waitlist. Un pilota che crea presentazioni di esempio ha un significato diverso da un workspace collegato a sistemi operativi.

Cloudflare dovrebbe inoltre distinguere gli utenti attivi da quelli registrati. Il valore della piattaforma dipende dal lavoro ripetuto, dalle applicazioni riutilizzabili e dalle competenze organizzative condivise.

Il terzo segnale è il modo in cui Microsoft, Google e Amazon rispondono al modello di workspace. I loro prodotti coprono già molte capacità circostanti e ciascuno può colmare le lacune attraverso integrazioni più strette.

Se le principali piattaforme aggiungono una provenienza tra sistemi più solida e competenze organizzative portabili, la distinzione di governance di Cloudflare si ridurrà. Se resteranno centrate sulle proprie suite, la posizione neutrale di Cloudflare diventerà più preziosa.

Cloudflare deve inoltre dimostrare che le sue versioni open source e gestita possano evolvere insieme. Il codice aperto attrae personalizzazione e scrutinio, mentre un servizio ospitato crea pressione per la stabilità.

Questa combinazione può diventare un vantaggio se i clienti possono ispezionare la piattaforma, controllare le integrazioni e passare tra modelli operativi. Diventa una passività se le release cambiano troppo rapidamente perché le imprese possano validarle.

Il workspace per agenti gestiti di Cloudflare OS è quindi più di un annuncio di hosting. Mette alla prova se le imprese desiderino un unico ambiente governato in cui i dipendenti possano fare ricerca, creare, programmare e automatizzare attraverso i sistemi esistenti.

Cloudflare ha presentato un'architettura credibile per questo ambiente. Non ha ancora presentato un prodotto gestito finito né prove indipendenti che il modello funzioni in imprese diverse.

Le organizzazioni che valutano la waitlist dovrebbero iniziare con workflow limitati e reversibili. Dovrebbero identificare i dati necessari, le azioni consentite, i punti di approvazione umana e le responsabilità per le competenze organizzative.

La domanda più utile non è se ogni dipendente debba ricevere un agente. È se un unico workspace governato possa sostituire in sicurezza una crescente raccolta di esperimenti con agenti scollegati.

Cloudflare deve ora dimostrare che operazioni gestite, accesso granulare e prodotti di lavoro persistenti possano rispondere a questa domanda in produzione.