Il provisioning di Databricks sostituisce gli spazi di lavoro condivisi con un distributore automatico pronto per gli agenti

Databricks ha sostituito un modello di spazi di lavoro condivisi ormai sotto pressione con un sistema di provisioning che serve oltre 5.000 utenti attivi su tre cloud. Il nuovo sistema di provisioning di Databricks offre agli ingegneri sul campo ambienti isolati che scadono automaticamente, invece di lasciare agli amministratori il compito di coordinare manualmente gli accessi.

L'azienda chiama l'applicazione interna Field Engineering Vending Machine, o FEVM. Il suo arrivo crea una chiara tensione tra due modelli infrastrutturali. Uno chiede alle persone di condividere ambienti di lunga durata e negoziare i conflitti. L'altro crea risorse temporanee e governate per ogni attività, comprese quelle avviate da agenti AI.

Questo cambiamento è rilevante perché Databricks conta ora oltre 7.000 persone nella sua organizzazione go-to-market. Gli ingegneri sul campo hanno spesso bisogno di controllo amministrativo per realizzare demo, riprodurre problemi dei clienti e testare funzionalità in anteprima. Gli spazi di lavoro condivisi sono diventati più difficili da governare man mano che il gruppo è cresciuto, passando da meno di 1.500 persone tre anni prima.

La storia immediata riguarda una revisione dell'infrastruttura interna. Quella più ampia riguarda chi controlla il provisioning cloud quando gli agenti possono richiedere risorse, distribuire codice, caricare dati ed eseguire workflow. FEVM trasforma l'intento espresso in linguaggio naturale in infrastruttura cloud, ma avvicina anche l'azione amministrativa al software autonomo.

Il provisioning di Databricks passa dalla capacità condivisa agli ambienti temporanei

Databricks ha reso l'infrastruttura isolata l'unità di lavoro predefinita per la propria organizzazione di field engineering.

Nel modello precedente, una piccola raccolta di spazi di lavoro condivisi supportava gran parte dell'organizzazione sul campo. La manutenzione manuale restava gestibile quando il field engineering contava meno di 1.500 persone. Questa configurazione è diventata instabile quando l'organizzazione go-to-market più ampia ha superato i 7.000 dipendenti.

Questo gruppo ha inoltre requisiti di accesso insoliti. Un tipico spazio di lavoro aziendale può contare su pochi amministratori che gestiscono molti utenti. Gli ingegneri sul campo di Databricks necessitano spesso di controllo a livello di amministratore perché il loro lavoro comprende configurazione, test e dimostrazioni specifiche per i clienti.

Più ingegneri che lavorano nello stesso ambiente possono ostacolarsi a vicenda. Una modifica apportata per una demo può influire su un altro ingegnere che sta preparando un incontro con un cliente. I limiti relativi a cataloghi, database e workload diventano inoltre vincoli operativi immediati quando molti team condividono la capacità.

Allo stesso tempo, l'attribuzione dei costi si indebolisce. Uno spazio di lavoro condiviso può mostrare il consumo totale senza indicare chiaramente quale ingegnere, scenario cliente o esperimento lo abbia generato. Un'attività imprevista richiede quindi indagini manuali tra log e sistemi.

FEVM cambia l'unità operativa: da uno spazio di lavoro condiviso da un gruppo a un ambiente associato a uno scopo e a un proprietario. Un ingegnere sceglie un modello, un provider cloud e una regione. La richiesta può includere aggiunte quali notebook, risorse Lakebase o asset pacchettizzati.

Il sistema quindi esegue il provisioning dell'ambiente e ne registra il ciclo di vita. Gli ambienti builder hanno una durata predefinita di 90 giorni, mentre altri tipi di risorse possono usare impostazioni di time-to-live differenti. Una policy time-to-live definisce quando una risorsa temporanea deve scadere ed essere rimossa.

Secondo il dettagliato resoconto di FEVM dell'azienda, le notifiche Slack segnalano quando il provisioning termina, quando si avvicina la scadenza e quando avviene l'eliminazione. Questa visibilità trasforma la pulizia da una responsabilità informale a un evento di sistema registrato.

FEVM gestisce inoltre alcune risorse in modo indipendente. Un catalogo può sopravvivere dopo la scomparsa dello spazio di lavoro a cui era collegato, per poi riconnettersi a un altro spazio di lavoro nella stessa regione. Questa separazione impedisce che il ciclo di vita di una risorsa controlli inutilmente tutto ciò che le sta intorno.

Il cambiamento importante non è quindi un modulo di richiesta più rapido. Databricks ha inserito creazione, proprietà, scadenza ed eliminazione in un unico processo governato. Tale processo si applica sia quando un essere umano usa l'interfaccia sia quando un agente chiama il servizio sottostante.

La scala ha reso l'accesso amministrativo il problema centrale

La pressione derivava da una forza lavoro che necessitava di un ampio controllo senza accettare il disordine che un controllo così esteso normalmente crea.

I team di field engineering operano in modo diverso dalla maggior parte dei gruppi aziendali interni. Devono rispondere rapidamente alle situazioni dei clienti, spesso con configurazioni che non possono attendere un team centrale di piattaforma. Limitare ogni ingegnere a un ruolo utente ristretto rallenterebbe il lavoro che dipende dal test di funzionalità amministrative.

Tuttavia, concedere a migliaia di persone un accesso esteso all'interno di spazi di lavoro condivisi crea il proprio collo di bottiglia. Ogni utente ottiene flessibilità, ma ogni modifica aumenta la possibilità di contese, proprietà poco chiare o interferenze accidentali. Gli amministratori della piattaforma finiscono quindi per dedicare più tempo al coordinamento di attività che il modello di accesso avrebbe dovuto accelerare.

FEVM affronta questa contraddizione spostando il controllo in ambienti isolati. Gli ingegneri mantengono la possibilità di configurare l'infrastruttura, mentre i modelli gestiti centralmente definiscono le condizioni iniziali. L'isolamento limita il raggio d'impatto di ogni esperimento senza costringere ogni richiesta a passare attraverso una coda manuale di ticket.

Databricks afferma che il sistema ha già gestito oltre 2.600 deployment attivi su AWS, Microsoft Azure e Google Cloud. Ha inoltre elaborato quasi 1.200 richieste di provisioning durante un solo giorno di BuildCon, un evento interno dedicato all'ingegneria.

Queste cifre provengono da Databricks e non hanno ricevuto una convalida indipendente. Mostrano comunque il modello di carico di lavoro per cui l'azienda ha progettato il sistema. La domanda arriva a ondate, coinvolge molti utenti e crea risorse che non dovrebbero restare attive indefinitamente.

Il sistema contava oltre 5.000 utenti attivi quando Databricks ha pubblicato il suo resoconto il 23 luglio 2026. L'azienda ha dichiarato di non aver riscontrato problemi di scalabilità a quel punto. Questa affermazione descrive un'esperienza interna, non una garanzia di prestazioni per i deployment dei clienti.

Questa scala cambia anche il significato del self-service infrastrutturale. Un piccolo team di piattaforma può tollerare eccezioni informali e supporto diretto. Migliaia di utenti richiedono modelli ripetibili, proprietà esplicita, pulizia automatica e registri che gli amministratori possano esaminare in seguito.

Portali per sviluppatori comparabili, inclusi i sistemi basati su Backstage, spesso presentano servizi e modelli approvati attraverso un catalogo condiviso. Anche i provider cloud offrono cataloghi di servizi per infrastrutture standardizzate. FEVM segue questo ampio modello di self-service, ma lo adatta al lavoro sul campo di Databricks e alle richieste guidate da agenti.

La pressione competitiva è quindi rivolta meno a un singolo fornitore che al modello manuale basato su ambienti condivisi. I team di piattaforma interni che continuano a usare ticket e sandbox di lunga durata hanno ora un'alternativa visibile. Possono esporre ambienti temporanei approvati senza rinunciare alle policy centralizzate.

Tuttavia, l'infrastruttura temporanea non elimina il lavoro di governance. Lo trasferisce in modelli, controlli delle identità, policy del ciclo di vita e registri di audit. Gli ingegneri di piattaforma devono mantenere con cura questi componenti, perché più utenti possono invocarli più frequentemente.

Databricks riconosce questa realtà operativa. L'azienda afferma che integrare workflow Git, identità aziendale, Slack, email e Terraform multi-cloud ha richiesto più impegno della creazione dell'interfaccia dell'applicazione. Questa ammissione è più istruttiva della metafora del distributore automatico.

Una casella di richiesta ben rifinita è soltanto il margine visibile. Il lavoro difficile si trova dietro di essa, dove l'identità deve seguire le richieste, le autorizzazioni devono restare delimitate e l'eliminazione deve avvenire senza rimuovere risorse che dovrebbero persistere.

Il meccanismo collega l'intento dell'utente all'infrastruttura multi-cloud

FEVM è importante perché tratta un caso d'uso, anziché una specifica grezza dello spazio di lavoro, come richiesta di provisioning.

Un ingegnere non deve iniziare elencando ogni risorsa necessaria. L'utente descrive un obiettivo, come preparare una demo per i servizi finanziari o riprodurre un problema di supporto. FEVM associa quell'obiettivo a un modello verificato ed espone opzioni di configurazione per cloud e regione.

L'applicazione usa un frontend React e un backend Python distribuiti tramite Databricks Apps. La piattaforma applicativa esegue applicazioni all'interno di Databricks e le collega a servizi quali Unity Catalog, SQL e autenticazione OAuth.

Terraform esegue il provisioning cloud sottostante. Terraform è un sistema di infrastructure-as-code: i team definiscono le risorse in configurazioni versionate anziché crearle tramite passaggi manuali non collegati tra loro. Il suo workflow dichiarativo può gestire risorse tramite API dei provider su AWS, Azure e Google Cloud.

Quando FEVM riceve una richiesta, seleziona il modello Terraform pertinente e lo invia a un runner basato su Git. Il workflow regola le autorizzazioni, effettua il provisioning delle aggiunte richieste e registra le risorse risultanti. Questa progettazione separa l'esperienza utente dal livello di esecuzione dell'infrastruttura.

Lakebase memorizza stato e configurazione del sistema. Lakebase è il servizio Postgres gestito di Databricks e la sua documentazione elenca lo stato applicativo per gli agenti AI tra i casi d'uso supportati. FEVM registra cosa sia ogni risorsa, chi ne sia proprietario, perché esista e quando scada.

Questo registro di stato è essenziale. Un agente può richiedere diverse operazioni dipendenti molto più rapidamente di un essere umano che naviga tra console separate. Senza un inventario affidabile, l'automazione può creare infrastruttura più velocemente di quanto gli amministratori riescano a comprenderla o rimuoverla.

L'interfaccia offre anche un catalogo di modelli. Gli esempi descritti da Databricks includono ambienti serverless stabili su AWS, configurazioni multi-cloud e ambienti con autoscaling Lakebase già configurato. I modelli consentono ai team centrali di codificare impostazioni predefinite approvate prima che arrivino le richieste.

Questa struttura crea un percorso controllato dall'intento all'azione:

• Un essere umano o un agente indica il caso d'uso.

• FEVM seleziona un modello di risorse approvato.

• Il richiedente sceglie parametri consentiti.

• Terraform crea le risorse cloud.

• Lakebase registra proprietà e stato del ciclo di vita.

• Le notifiche rendono visibili gli eventi di provisioning ed eliminazione.

• Le policy di scadenza rimuovono l'infrastruttura temporanea.

Ogni passaggio riduce l'ambiguità. Il linguaggio naturale può esprimere l'obiettivo, ma il modello approvato determina quale infrastruttura il sistema creerà effettivamente. Questo confine distingue l'accesso governato degli agenti da un chatbot senza restrizioni collegato a credenziali cloud.

Il meccanismo supporta anche workflow composti. Databricks descrive uno scenario in cui un ingegnere chiede a un agente di creare uno spazio di lavoro, distribuire Databricks Asset Bundles locali, caricare dati da Amazon S3 ed eseguire uno script di hydration per una dashboard.

Uno script di hydration popola un nuovo ambiente con i dati o la configurazione necessari. Dal punto di vista dell'utente, una sola richiesta può attivare l'intera sequenza. Dal punto di vista del team di piattaforma, ogni azione richiede comunque strumenti autenticati, parametri approvati e stato osservabile.

È qui che il Model Context Protocol entra nel progetto. MCP è uno standard aperto che consente alle applicazioni AI di connettersi a strumenti e fonti di dati tramite un'interfaccia comune. La panoramica ufficiale di MCP lo descrive come un modo per consentire agli agenti di accedere a flussi di lavoro esterni e compiere azioni.

Databricks afferma che FEVM utilizza MCP come punto di controllo centrale per interfacce chat, servizi esterni e agenti. Le skill di Claude pubblicate centralmente possono aggirare l'interfaccia grafica e chiamare le API di FEVM. Un file di skill indica all'agente come invocare il flusso di lavoro approvato.

Ciò non significa che il modello linguistico esegua direttamente il provisioning dell'infrastruttura. L'agente invia una richiesta a un servizio controllato, che applica template e regole di identità. Terraform, i flussi di lavoro Git e il backend di FEVM svolgono il lavoro con conseguenze operative.

Questa separazione è la decisione ingegneristica centrale. Il linguaggio naturale gestisce l'intento, mentre sistemi infrastrutturali deterministici gestiscono l'esecuzione. Il modello può aiutare a selezionare e coordinare gli strumenti, ma non sostituisce la gestione dello stato o i controlli del ciclo di vita sottostanti.

L'accesso agent-first aumenta il costo di un template errato

La stessa astrazione che rende semplici le richieste sicure può diffondere un errore di configurazione a migliaia di utenti.

Databricks afferma che i nuovi template vengono verificati, rafforzati e testati ripetutamente. L'azienda rileva inoltre che il suo team opera con eccezioni di sicurezza perché FEVM automatizza azioni amministrative su infrastrutture backend reali.

Questa dichiarazione individua la principale incertezza. FEVM concentra l'autorità dietro un'interfaccia pratica. Se autorizzazioni, mappatura delle identità o un template sono errati, un agente può invocare il percorso difettoso in modo coerente e ad alta frequenza.

Un processo manuale introduce attrito, ma quell'attrito talvolta dà a un operatore il tempo di notare una richiesta insolita. L'automazione elimina questa pausa. Il sostituto deve invece utilizzare controlli delle policy, parametri vincolati, confini di approvazione e registri di audit completi.

La qualità dei template diventa quindi un confine di sicurezza. Un template può determinare quali percorsi di rete esistono, quali identità ricevono accesso, quali dati diventano disponibili e quali risorse sopravvivono all'eliminazione. La qualità della revisione conta quanto la velocità di deployment.

Il linguaggio naturale aggiunge un'altra incertezza. Una richiesta può essere incompleta, ambigua o basata su un presupposto errato. FEVM deve tradurre l'intento in un caso d'uso noto senza ampliare silenziosamente l'ambito di ciò che il richiedente ha chiesto.

Databricks non ha pubblicato misurazioni dettagliate relative a richieste non riuscite, rifiuti delle policy, selezione errata dei template, errori di pulizia o tempo medio di provisioning. Queste misure rivelerebbero più sulla qualità operativa rispetto al solo numero di deployment.

L'azienda non ha neppure descritto con quale frequenza gli esseri umani debbano intervenire dopo che un agente avvia un flusso di lavoro in più fasi. Una richiesta infrastrutturale riuscita può comunque produrre un ambiente inutilizzabile se il caricamento dei dati, il deployment dei bundle o gli script downstream falliscono.

Anche la visibilità dei costi richiede un esame simile. FEVM associa le risorse a proprietari e finalità, migliorando l'attribuzione. Tuttavia, la descrizione pubblica non fornisce dati sulla spesa cloud prima e dopo, sulle riduzioni delle risorse inattive o sul costo di gestione della piattaforma stessa.

La scadenza automatica può ridurre l'infrastruttura abbandonata, ma un'impostazione predefinita di 90 giorni è comunque abbastanza lunga da consentire l'accumulo di risorse costose. Tipi diversi di carichi di lavoro richiedono limiti differenti. Anche le policy di estensione necessitano di revisione, affinché gli ambienti temporanei non diventino permanenti tramite rinnovi ordinari.

Il supporto multi-cloud amplia la sfida. AWS, Azure e Google Cloud dispongono di sistemi di identità, quote, servizi regionali e modalità di errore differenti. Un'interfaccia di richiesta comune può nascondere tali differenze agli utenti, ma il team della piattaforma deve comunque gestirle.

I limiti della piattaforma rappresentano un altro punto di pressione. Databricks segnala limiti rigidi che coinvolgono le risorse Unity Catalog e Lakebase. La gestione centralizzata del ciclo di vita aiuta a evitare tali soglie, ma non le elimina. La domanda può comunque superare la capacità disponibile o creare contese regionali.

Lakebase supporta lo stato transazionale delle applicazioni, la scalabilità automatica e branch isolati, secondo la sua documentazione Postgres. L'affidabilità di FEVM dipende comunque da come il proprio schema, i processi di riconciliazione e la logica di ripristino utilizzano tali capacità.

Databricks afferma che il team ha ristrutturato FEVM due volte, comprese modifiche allo schema del database, al frontend e alla gestione dello stato. Questa storia suggerisce che il progetto abbia richiesto un'iterazione significativa. Invita inoltre a non trattare l'architettura attuale come una semplice implementazione di riferimento.

L'azienda ha utilizzato l'AI per accelerare la scrittura del codice, ma afferma che gli esseri umani hanno mantenuto il controllo sull'architettura. Questa divisione è sensata per un sistema che gestisce infrastrutture privilegiate. Il codice generato può accelerare l'implementazione, mentre la revisione umana resta responsabile dei confini e del recupero dagli errori.

La scala riportata da FEVM dimostra che i dipendenti desiderano un provisioning più rapido. Non dimostra ancora che le richieste avviate dagli agenti offrano la stessa affidabilità, sicurezza o controllo dei costi delle richieste umane attentamente esaminate. Tali affermazioni richiedono dati operativi di più lunga durata e metriche più chiare.

Il vero avversario è lo spazio di lavoro condiviso di lunga durata

FEVM sostituisce il coordinamento con l'isolamento, ma solo rendendo più importante la policy centrale della piattaforma.

Gli spazi di lavoro condivisi appaiono inizialmente efficienti. I team riutilizzano infrastrutture comuni, evitano configurazioni ripetute e mantengono le risorse in un'unica posizione visibile. Questi vantaggi si indeboliscono quando la maggior parte degli utenti necessita di un ampio controllo e il lavoro sui clienti richiede configurazioni incompatibili.

Alla scala attuale di Databricks, gli ambienti condivisi trasformano il coordinamento in lavoro nascosto. Gli ingegneri devono evitare collisioni, gli amministratori devono tracciare la proprietà e i team devono decidere chi può modificare le risorse comuni. Una dimostrazione critica può dipendere dal fatto che un altro utente non modifichi lo stesso ambiente.

Il provisioning isolato inverte questa relazione. Ogni ingegnere riceve un ambiente realizzato per uno scopo specifico senza dover negoziare con tutti gli altri. Il team della piattaforma standardizza template e regole del ciclo di vita anziché mediare conflitti tra singoli spazi di lavoro.

Il cambiamento modifica anche il modo in cui le aziende dovrebbero valutare l'utilizzo. Un ambiente condiviso può apparire efficiente perché molte persone usano un unico spazio di lavoro. Eppure questa metrica ignora i tempi di attesa, la deriva della configurazione, le dimostrazioni fallite e lo sforzo investigativo.

Gli ambienti temporanei possono apparire meno efficienti perché il sistema crea più spazi di lavoro. Possono comunque produrre meno sprechi operativi quando la proprietà è chiara e la pulizia avviene automaticamente. Databricks non ha pubblicato dati sui costi sufficienti a stabilire questo risultato, ma il progetto lo rende misurabile.

Questo schema ricorda gli ambienti di sviluppo effimeri utilizzati nella distribuzione software. I team creano un ambiente pulito per un branch, un test o una revisione, quindi lo rimuovono al termine del lavoro. FEVM applica un ciclo di vita simile all'ingegneria sul campo per dati e AI.

L'elemento agentico rafforza l'argomentazione a favore dell'isolamento. Una persona che lavora tramite un'interfaccia grafica esegue di norma le operazioni in sequenza. Un agente può coordinare più strumenti e creare diverse risorse a partire da una sola istruzione.

Eseguire tali operazioni in uno spazio di lavoro condiviso affollato aumenterebbe la probabilità di interazioni inattese. Un ambiente isolato offre al flusso di lavoro una posizione delimitata. Offre inoltre agli amministratori un'unità più chiara per attribuzione, scadenza ed eliminazione.

Tuttavia, l'isolamento può creare proliferazione se inventario e pulizia falliscono. La risposta non è il solo isolamento. È l'isolamento abbinato a stato gestito centralmente, proprietà, notifiche e applicazione del ciclo di vita.

Ecco perché l'etichetta del distributore automatico è utile ma incompleta. Un distributore automatico presenta un piccolo catalogo e consegna un articolo prevedibile. FEVM deve anche autenticare il richiedente, interpretare l'intento, creare infrastrutture distribuite, monitorare i limiti e infine annullare ogni modifica.

La piattaforma assomiglia più a un control plane interno che a una semplice applicazione. Un control plane è il livello di gestione che decide quali risorse dovrebbero esistere e coordina il loro ciclo di vita. FEVM si colloca tra utenti o agenti e i cloud sottostanti.

Questa posizione offre a Databricks un terreno di prova diretto per le proprie tecnologie applicative, di database, governance e agenti. Crea anche un incentivo a presentare l'uso interno riuscito come prova per la piattaforma più ampia.

I lettori dovrebbero distinguere queste due affermazioni. FEVM può essere una soluzione interna credibile senza dimostrare che ogni impresa possa riprodurla facilmente. L'organizzazione sul campo di Databricks dispone di competenze specialistiche, accesso approfondito alla piattaforma e autorità per mantenere integrazioni tra sistemi aziendali.

Altre imprese possono dipendere da piattaforme dati separate, provider di identità, sistemi di ticketing, motori di policy e account cloud. Il loro lavoro di integrazione può superare lo sforzo necessario per costruire l'interfaccia utente. La stessa descrizione di Databricks afferma che tale integrazione ha prodotto gran parte della difficoltà ingegneristica e del valore di FEVM.

La lezione non è che ogni azienda abbia bisogno di un distributore automatico identico. È che l'infrastruttura guidata dagli agenti richiede un confine di servizio governato. Gli spazi di lavoro condivisi di lunga durata e le credenziali ad hoc diventano più difficili da difendere una volta che gli agenti software possono avviare flussi di lavoro complessi.

Tre segnali mostreranno se FEVM è pronto per l'era agentica

Il prossimo test è se Databricks riuscirà ad ampliare l'accesso degli agenti preservando sicurezza, pulizia e risultati operativi prevedibili.

Il primo segnale è l'espansione pianificata dell'interfaccia in linguaggio naturale di FEVM. Databricks vuole che gli ingegneri descrivano le situazioni dei clienti mentre il sistema identifica l'infrastruttura adatta. Una migliore gestione dell'intento rafforzerebbe l'idea che il provisioning basato sui casi d'uso possa sostituire la specifica manuale.

L'evidenza utile non sarà un'altra dimostrazione di una richiesta riuscita. Databricks dovrebbe riferire con quale frequenza l'interfaccia seleziona il template corretto, chiede chiarimenti, rifiuta richieste non supportate o richiede una correzione umana.

Tassi di correzione bassi sosterrebbero il modello agent-first. Una classificazione errata frequente dimostrerebbe che la ricerca in un catalogo resta più sicura del linguaggio aperto per azioni infrastrutturali privilegiate.

Il secondo segnale è l'integrazione MCP più ampia per l'accesso basato sugli strumenti. Databricks afferma che la distribuzione di tale integrazione è una delle sue prossime priorità. MCP consentirebbe a più client agentici di raggiungere FEVM tramite un'interfaccia comune per gli strumenti, anziché richiedere un flusso di lavoro grafico dedicato.

La domanda chiave è come FEVM delimiti l'autorità tra questi client. Una forte propagazione dell'identità, strumenti vincolati, approvazioni chiare e tracce di audit complete rafforzerebbero il progetto. Credenziali ampie o una delega poco chiara lo indebolirebbero.

I team di sicurezza dovrebbero anche verificare se le azioni degli agenti restano distinguibili dai loro sponsor umani. Un record di audit utile dovrebbe collegare il dipendente, la sessione dell'agente, il template selezionato, la finalità richiesta, le risorse risultanti e l'eliminazione successiva.

Il terzo segnale è l'espansione nell'intera organizzazione go-to-market. Più utenti verificheranno se i template restano comprensibili al di fuori del pubblico originale dell'ingegneria sul campo. Creeranno inoltre nuovi modelli di carico di lavoro e richieste di supporto.

I soli dati di adozione non risolveranno la questione. Le misure più solide sono il successo del provisioning, il tempo per ottenere un ambiente utilizzabile, i tassi di rifiuto delle policy, la pulizia delle risorse scadute, il costo per caso d'uso e la frequenza dell'intervento umano.

Databricks può rafforzare la propria tesi pubblicando questi risultati operativi nel tempo. Può indebolirla concentrandosi solo sui totali di utenti attivi e deployment, lasciando senza spiegazione fallimenti, costi ed eccezioni di sicurezza.

Per gli sviluppatori, FEVM mostra come gli agenti possano operare tramite strumenti infrastrutturali senza ricevere un accesso illimitato al cloud. Per gli acquirenti enterprise, offre un criterio concreto per valutare la governance degli agenti: ogni azione dovrebbe avere un responsabile, uno scopo, un percorso di policy e una regola di scadenza.

I knowledge worker dovrebbero interessarsene perché lo stesso schema raggiungerà altri sistemi aziendali. Gli agenti richiederanno accesso, configureranno ambienti di progetto, recupereranno contesto e coordineranno strumenti. La qualità del livello di controllo conterà più della fluidità dell'interfaccia chat.

I team che sviluppano workflow simili necessitano inoltre di documentazione duratura al di fuori del servizio di provisioning. Una base di conoscenza ricercabile può conservare le decisioni sui template, le conclusioni sugli incidenti e il contesto operativo per gli ingegneri che esaminano le azioni degli agenti.

Il provisioning di Databricks opera già su un'insolita scala interna, ma la sua fase più significativa deve ancora arrivare. Occorre osservare se le richieste in linguaggio naturale restano circoscritte, se l'accesso MCP preserva l'identità e se un'adozione più ampia migliora i risultati senza ampliare i rischi.

La domanda pratica per ogni team di piattaforma è ora chiara: la vostra infrastruttura è in grado di spiegare chi ha richiesto ogni risorsa, perché esiste e quando verrà rimossa? Se un agente non può operare entro questi confini, un provisioning più rapido crea semplicemente incertezza più rapidamente.