Databricks Unity Gateway CLI mette la scelta degli agenti di coding dietro un unico piano di controllo

Databricks ha lanciato Unity Gateway CLI dopo che quattro grandi famiglie di modelli sono cambiate nell’arco di sei mesi, rendendo la scelta degli agenti di coding un bersaglio mobile per le aziende. Databricks Unity Gateway CLI offre agli amministratori un unico percorso governato per modelli, strumenti, skill, utilizzo e spesa. Gli sviluppatori possono comunque aprire il proprio agente preferito con comandi quali ug claude o ug codex.

Questa combinazione crea la vera tensione. Databricks non chiede alle organizzazioni di engineering di standardizzare su un unico agente di coding. Vuole che standardizzino sul gateway sottostante a ogni agente, per poi modificare modelli e policy senza ricostruire la configurazione di ciascuno sviluppatore.

L’alternativa principale è l’amministrazione diretta e specifica per fornitore. OpenAI, Anthropic, Google e altri vendor possono governare i propri prodotti, spesso con controlli progettati attorno ai rispettivi ambienti nativi. Databricks scommette sul fatto che le imprese attribuiranno più valore a un piano di controllo condiviso che all’integrazione più stretta di stack separati per fornitore.

Databricks Unity Gateway CLI centralizza la configurazione degli agenti

Il rilascio trasforma la configurazione degli agenti di coding da un’attività svolta sviluppatore per sviluppatore in un’infrastruttura pubblicata centralmente.

Gli amministratori configurano agenti approvati, modelli predefiniti, server Model Context Protocol, skill riutilizzabili, comportamento di routing e policy di spesa in Unity Gateway. MCP è uno standard che consente a un agente AI di richiamare strumenti esterni e recuperare dati contestuali attraverso un’interfaccia coerente.

Dopo che un amministratore pubblica una configurazione, la CLI la recupera e la applica quando uno sviluppatore avvia un agente. Databricks afferma che un’organizzazione può anche bloccare impostazioni selezionate e distribuire la CLI tramite il proprio sistema di gestione dei dispositivi.

L’interfaccia iniziale rimane volutamente ridotta. Uno sviluppatore può digitare ug claude, ug codex, ug gemini, ug opencode, ug copilot o ug pi. La CLI autentica quindi l’utente, collega il programma selezionato a Unity Gateway, applica la configurazione dell’organizzazione e apre la familiare interfaccia terminale dell’agente.

Cursor occupa una posizione più circoscritta. Il repository CLI open source afferma che Unity Gateway configura i server MCP per Cursor Agent, ma i modelli di Cursor continuano a essere eseguiti attraverso l’account Cursor dello sviluppatore. Questa distinzione è importante perché il supporto per un’interfaccia agente non garantisce un routing dei modelli identico in ogni client.

La sincronizzazione della configurazione è il cambiamento più ampio. Se un amministratore modifica un modello predefinito, la nuova scelta appare quando gli sviluppatori avviano successivamente l’agente pertinente tramite ug. L’azienda descrive anche rollout basati su coorti, che offrono ai team di piattaforma un modo per testare un nuovo modello con un gruppo limitato prima di una distribuzione più ampia.

Questo design separa l’agent harness dal modello che vi sta dietro. Un agent harness è il software che pianifica il lavoro, richiama strumenti, modifica file e gestisce una sessione di coding. Il modello linguistico fornisce ragionamento e generazione, ma l’harness circostante determina come tali capacità raggiungono un repository.

Un team può quindi mantenere Claude Code come interfaccia, modificando al contempo la configurazione del modello consentita dal proprio gateway. Un altro gruppo può continuare a usare Codex, ricevendo però gli stessi strumenti MCP approvati e le stesse regole di spesa.

L’approccio affronta un reale onere operativo. Ogni agente dispone normalmente di file di configurazione, convenzioni di autenticazione, formati per la registrazione degli strumenti e variabili d’ambiente propri. Supportare più agenti può moltiplicare gli script di configurazione e lasciare gli sviluppatori con policy incoerenti.

Databricks ora gestisce i file per i client supportati e conserva un record locale della configurazione applicata. La documentazione del repository afferma che lo strumento esegue il backup dei file prima di modificarli e offre ug revert per ripristinare tali backup. Un comando ug doctor può diagnosticare problemi di configurazione, mentre ug status segnala workspace, modelli, skill e file generati configurati.

Il risultato non è un nuovo agente di coding. È un livello di distribuzione che fa comportare più agenti come client di un unico servizio aziendale. Questo cambiamento prepara il confronto centrale del rilascio: un gateway condiviso contro piani di controllo separati per fornitore.

La crescita degli agenti di coding mette sotto pressione i team di piattaforma

La pressione immediata ricade sui team di piattaforma, sicurezza e finanza, che devono governare strumenti adottati dagli sviluppatori più rapidamente di quanto le policy aziendali riescano a tenere il passo.

Databricks ha introdotto la CLI il 24 settembre 2026. Il suo annuncio di lancio cita GPT-6, Claude Opus 5.5, Gemini 3.8 e Grok 4.7 come rilasci dei sei mesi precedenti. Cita inoltre modelli open-weight, tra cui Kimi K3, GLM-5 e DeepSeek V4.1.

L’azienda stima che un nuovo modello frontier compaia ormai all’incirca ogni cinque giorni. Tale stima è una caratterizzazione di Databricks, non una misurazione standardizzata del settore. Tuttavia, la cadenza dei rilasci spiega perché un valore predefinito aziendale fisso possa invecchiare rapidamente.

La qualità del modello è solo una variabile. Un modello più piccolo può completare modifiche di routine a costi inferiori, mentre un modello più capace può ottenere risultati migliori in una migrazione estesa all’intero repository. Disponibilità, latenza, gestione del contesto, uso degli strumenti e requisiti regionali possono anch’essi modificare la scelta appropriata.

Senza un livello condiviso, le aziende affrontano due opzioni scomode. Possono standardizzare su un singolo provider e accettare che un altro modello possa diventare migliore per una determinata attività. In alternativa, possono supportare più agenti e provider, quindi replicare tra essi policy di identità, budget, logging e strumenti.

La seconda strada preserva la scelta ma amplia la superficie amministrativa. Uno sviluppatore può usare una credenziale per un agente, un altro token per un servizio MCP e una chiave separata per un provider di modelli. I record di utilizzo possono finire in console differenti, con metodi di attribuzione non allineati.

Unity Gateway prova a concentrare questi percorsi. Secondo la documentazione sulla governance dell’azienda, le richieste a modelli e MCP possono transitare attraverso un livello comune che applica autorizzazioni, limiti di velocità, policy di servizio e registrazione dell’utilizzo. Unity Catalog fornisce il modello di accesso sottostante.

Questa architettura consente agli amministratori di concedere l’accesso ai modelli a utenti o gruppi nominati anziché distribuire segreti dei provider. L’agente si autentica con credenziali Databricks e il gateway fornisce le credenziali del provider archiviate quando inoltra una richiesta approvata.

Databricks documenta limiti di richieste al minuto e token al minuto a livello di servizio del modello. I limiti possono essere applicati globalmente o per utente. Una tabella di sistema sull’utilizzo registra il richiedente, il servizio, lo stato della risposta e altri dati operativi per il traffico che raggiunge il gateway.

Questo è particolarmente rilevante quando gli agenti di coding possono richiamare strumenti. Una risposta del modello consuma token, ma una sessione agente può anche cercare nei repository, interrogare database, invocare funzioni interne o contattare servizi esterni. L’accesso agli strumenti crea un problema di policy più ampio rispetto al solo accesso ai modelli.

La registrazione centralizzata di MCP offre ai team di piattaforma un set di strumenti curato. Anziché chiedere a ogni sviluppatore di incollare definizioni di server in vari file di configurazione locali, gli amministratori possono pubblicare servizi approvati e renderli disponibili tra agenti compatibili.

I team hanno comunque bisogno di una documentazione interna accurata per repository, API e procedure operative. Una base di conoscenza per l’engineering consultabile può fornire quel contesto, mentre il gateway governa il modo in cui un agente raggiunge strumenti approvati.

La pressione è sia di breve termine sia strutturale. I team di piattaforma necessitano di un modo immediato per integrare l’agente più recente senza duplicare i controlli. Nel tempo, devono anche evitare che il loro modello di governance rimanga legato al ciclo di rilascio di un singolo fornitore di modelli.

Ecco perché il prodotto si rivolge a organizzazioni con preferenze eterogenee tra gli sviluppatori. Se ogni ingegnere usa lo stesso fornitore e modello, un ulteriore livello amministrativo può offrire vantaggi limitati. Il caso diventa più forte quando team differenti insistono su harness diversi, ma la sicurezza richiede comunque un unico percorso responsabile.

Un gateway ora compete con piani di controllo separati per fornitore

Databricks scommette sul fatto che la portabilità centralizzata conti più della gestione di ogni agente di coding nell’ambiente enterprise nativo del suo fornitore.

I piani di controllo nativi dei fornitori hanno un chiaro vantaggio. I loro amministratori possono governare funzionalità specifiche del prodotto, inclusi ambienti di esecuzione, connessioni ai repository, modalità di approvazione, impostazioni di conservazione e telemetria specializzata.

OpenAI, per esempio, descrive controlli del workspace, sandboxing, requisiti di policy e telemetria consapevole degli agenti nel suo resoconto su come eseguire Codex in sicurezza. Questi controlli riguardano il comportamento dell’agente completo, non soltanto il modo in cui il traffico dei suoi modelli e strumenti raggiunge un gateway.

Anthropic e altri fornitori di agenti seguono lo stesso schema generale. Ciascuno può ottimizzare la gestione attorno al proprio harness, alla propria famiglia di modelli, al proprio sistema di autorizzazioni e alla propria cadenza di aggiornamento. Questa integrazione verticale può semplificare il supporto quando un’azienda si impegna su un unico prodotto.

Unity Gateway propone un modello orizzontale. Il gateway diventa il confine stabile delle policy, mentre interfacce degli agenti e modelli predefiniti possono cambiare. Non deve sostituire ogni salvaguardia nativa per creare valore. Deve far transitare traffico sufficiente attraverso i suoi controlli affinché identità centralizzata, costi e policy sugli strumenti assumano significato.

La distinzione risulta più semplice da vedere quando un’azienda vuole cambiare modello. In una distribuzione specifica per fornitore, i team potrebbero dover aggiornare la configurazione locale, predisporre nuove credenziali, modificare le allowlist e ricreare la reportistica sull’utilizzo. Il lavoro esatto dipende dall’agente e dal provider.

Con Databricks Unity Gateway CLI, un amministratore può modificare un modello predefinito pubblicato. L’avvio successivo applica tale impostazione senza richiedere a ogni sviluppatore di modificare le impostazioni dell’agente. I controlli per coorti possono limitare il cambiamento a utenti selezionati durante la valutazione.

Il supporto per provider esterni amplia questa proposta. La documentazione di Azure Databricks di Microsoft afferma che Claude Code e Codex possono instradare le richieste attraverso servizi provider registrati in Unity Catalog. Tali servizi possono rappresentare OpenAI, Anthropic, Amazon Bedrock o un altro provider supportato.

L’agente invia la propria richiesta a un endpoint Unity Gateway, mentre un’intestazione della richiesta identifica il servizio provider previsto. Il gateway fornisce il segreto archiviato, verifica l’accesso e registra l’utilizzo. Gli sviluppatori non hanno bisogno della chiave del provider upstream sulle loro macchine.

Questa portabilità ha dei limiti. Il modello sottostante deve rimanere compatibile con l’agente selezionato e ogni harness può aspettarsi comportamenti delle richieste specifici del provider. Un gateway non può rendere automaticamente ogni modello compatibile con tutte le funzionalità proprietarie di ogni agente.

Anche la matrice degli agenti supportati varia in base alle funzionalità. Alcuni client accettano modelli, server MCP e skill configurati centralmente. Cursor riceve attualmente la configurazione MCP senza che il suo traffico di modelli venga trasferito a Databricks. Anche il routing verso provider esterni è più sviluppato per alcuni agenti rispetto ad altri.

Queste differenze impediscono a Unity Gateway di diventare una presa perfettamente intercambiabile per tutti gli strumenti di coding. La piattaforma deve stare al passo con formati di configurazione e comportamenti di autenticazione in evoluzione tra diversi client sviluppati in modo indipendente.

Il progetto open source rende visibile questa attività di manutenzione. I suoi adattatori scrivono file specifici per gli agenti per Codex, Claude Code, Gemini CLI, OpenCode, GitHub Copilot CLI, Pi e Cursor. Ogni modifica alla configurazione upstream può trasformarsi in lavoro di compatibilità per Databricks.

Tuttavia, l'apertura offre agli acquirenti anche un modo per ispezionare l'integrazione. I team possono esaminare il repository, testare le modifiche in ambienti controllati e verificare quali file vengono gestiti dalla CLI. Questa trasparenza è utile quando uno strumento modifica le impostazioni sulle macchine degli sviluppatori.

L'approccio orizzontale scambia quindi profondità con coerenza. I sistemi nativi dei fornitori possono controllare più comportamenti specifici del prodotto. Unity Gateway può offrire identità comune, accesso ai modelli, registrazione MCP, budgeting e reportistica su una raccolta più ampia di interfacce.

Il vincitore non sarà determinato soltanto da una checklist di funzionalità. Le aziende valuteranno se i controlli condivisi coprono i rischi che devono effettivamente gestire e se il gateway aggiunge un carico operativo inferiore a quello che rimuove.

Lo Smart Routing collega la scelta del modello alla spesa

L'argomento economico del prodotto dipende dall'instradare il lavoro ordinario verso modelli meno costosi senza costringere gli sviluppatori a gestire la selezione del modello per ogni sessione.

Le richieste di coding variano notevolmente. Rinominare una variabile non richiede la stessa capacità di ragionamento necessaria per diagnosticare un guasto distribuito che coinvolge diversi servizi. Se ogni attività utilizza il modello approvato più potente, un'azienda può pagare un sovrapprezzo anche quando il lavoro è semplice.

Lo Smart Routing di Unity Gateway sceglie un modello per la sessione principale e può selezionarne uno separatamente per il lavoro delegato a un subagente. Databricks afferma che il proprio benchmark interno sul coding ha mostrato un risparmio sui costi del 35% grazie a questo approccio.

Questa cifra va interpretata come una valutazione interna, non come un risultato universale. I risparmi disponibili per un'altra organizzazione dipenderanno dal mix di attività, dai modelli idonei, dall'accuratezza dell'instradamento, dalle condizioni dei fornitori e dalla tolleranza verso i tentativi ripetuti.

Un primo tentativo meno costoso può diventare oneroso se fallisce ripetutamente o produce codice che richiede più revisione. Al contrario, instradare ogni richiesta a un modello ad alta capacità può sprecare budget per modifiche prevedibili. Un router utile deve distinguere questi casi in modo affidabile.

Databricks supporta anche impostazioni predefinite sensibili al budget. Quando l'utilizzo raggiunge una soglia definita, gli amministratori possono consigliare un agente o modello meno costoso per i nuovi avvii. Le sessioni attive proseguono invece di cambiare modello nel mezzo del lavoro.

I controlli di spesa dell'azienda distinguono tra budget condivisi, limiti per utente e deroghe per utenti o gruppi selezionati. Gli amministratori possono attivare avvisi, bloccare ulteriori richieste al gateway o applicare entrambe le azioni.

L'applicazione del budget si basa su stime quasi in tempo reale. Le richieste già in esecuzione possono concludersi, quindi il consumo finale può superare una soglia. Anche la spesa stimata presso fornitori esterni può differire dalla fattura finale del fornitore.

Le impostazioni predefinite non equivalgono a restrizioni rigide. Databricks afferma che le impostazioni intelligenti influenzano i nuovi avvii, ma non impediscono a uno sviluppatore autorizzato di selezionare un altro modello disponibile. Le autorizzazioni di Unity Catalog o il blocco del budget garantiscono un'applicazione più rigorosa.

Lo Smart Routing presenta ulteriori limiti. Attualmente funziona con Claude Code e Codex, e il relativo elenco documentato di candidati è limitato ai servizi modello sotto system.ai. Databricks afferma che non può essere combinato con un modello personalizzato, un fornitore esterno, una location di Unity Catalog o un altro servizio modello al di fuori di quello spazio dei nomi.

Queste restrizioni riducono la portata della narrativa sulla portabilità. Un'organizzazione può centralizzare modelli esterni attraverso il gateway, ma non può necessariamente includerli nello stesso ciclo di ottimizzazione automatizzata. Gli acquirenti che cercano un routing neutrale rispetto ai fornitori dovrebbero testare attentamente questo confine.

Il tracing fornisce il meccanismo di feedback. Databricks afferma che Unity Gateway può raccogliere attività dei modelli, chiamate a strumenti locali e invocazioni di skill in una tabella di traccia unificata. Gli amministratori possono quindi investigare su ripetuti errori degli strumenti, output eccessivamente grandi e altri pattern che consumano token senza far avanzare il compito.

L'azienda riferisce di aver utilizzato questo processo con Genie One per identificare sette bug negli strumenti MCP. Databricks stima che correggerli abbia evitato 1,2 milioni di dollari all'anno in spesa AI sprecata e perdita di produttività.

Anche in questo caso, il numero è una stima aziendale tratta dal proprio ambiente. Combina la spesa diretta per i modelli con una stima della perdita di produttività, quindi i lettori non dovrebbero considerarlo un benchmark trasferibile del ritorno sull'investimento.

Un esempio di cliente offre un segnale di scala differente. Il CTO di Concurrence John Xing afferma che l'azienda ha instradato oltre 61 miliardi di token di input per agenti di coding attraverso circa 360.000 richieste dopo aver adottato Unity Gateway. Descrive una visibilità centralizzata su utilizzo e spesa con attribuzione a livello di identità.

Questa testimonianza dimostra che il sistema ha gestito un traffico di produzione sostanziale per almeno un cliente nominato. Non divulga latenza, tassi di errore, accettazione del codice, risultati di sicurezza o il modo in cui l'organizzazione ha misurato la soddisfazione degli sviluppatori.

Il caso economico resta quindi un meccanismo, non un risultato garantito. Il routing centralizzato crea l'opportunità di adeguare il costo alla complessità del compito. Il tracing può esporre gli sprechi. I budget possono contenere i consumi. I risparmi effettivi dipendono comunque da quanto bene le policy si adattano al reale lavoro di ingegneria.

La governance centrale presenta ancora lacune di copertura

Un gateway governa soltanto il traffico, i client e gli strumenti che effettivamente lo attraversano.

Gli sviluppatori possono aggirare il piano di controllo avviando direttamente un agente nativo, a meno che l'organizzazione non imponga il percorso gestito tramite policy dei dispositivi, credenziali, controlli di rete o standard interni. Databricks osserva esplicitamente che le sessioni native di Claude Code e Codex al di fuori della CLI di Unity Gateway non ricevono il suo Smart Routing.

La copertura del traffico è quindi la prima domanda da porsi durante una valutazione. Un amministratore dovrebbe determinare se ogni richiesta al modello, invocazione MCP e attività delegata raggiunge il gateway. Un instradamento parziale può produrre un registro di audit incompleto pur creando l'impressione di un controllo centralizzato.

Il secondo problema è l'esecuzione locale. Un gateway può autorizzare un modello e registrare il traffico degli strumenti, ma un agente di coding può anche leggere file, eseguire comandi shell, installare pacchetti o modificare un repository sulla macchina dello sviluppatore. Queste azioni dipendono dal sandboxing, dal sistema di approvazione e dalle policy locali dell'harness.

È qui che i controlli enterprise nativi restano rilevanti. La governance dei modelli non sostituisce la sicurezza degli endpoint, le autorizzazioni dei repository, le protezioni dei branch, la revisione del codice, la gestione dei segreti o i limiti di esecuzione dell'agente stesso.

MCP amplia ulteriormente il confine di fiducia. Un server approvato può comunque esporre capacità molto ampie, restituire contenuti non attendibili o attivare effetti collaterali. Gli amministratori devono esaminare i singoli strumenti, limitare le credenziali e decidere quali azioni richiedono conferma.

L'attribuzione a livello di identità aiuta un'indagine, ma l'attribuzione da sola non rende sicuro uno strumento. Una traccia può mostrare chi ha avviato un'operazione dopo il fatto. I controlli preventivi devono comunque limitare ciò che quell'identità e l'agente sono autorizzati a fare.

La proprietà della configurazione introduce inoltre una tensione. Gli sviluppatori mantengono spesso impostazioni degli agenti accuratamente calibrate, server MCP locali e istruzioni specifiche per il flusso di lavoro. La configurazione centrale può sovrascrivere o entrare in conflitto con queste scelte.

Databricks attenua questo rischio con backup, file gestiti, impostazioni bloccate, anteprime dry-run e un comando di ripristino. Le aziende dovrebbero comunque testare gli aggiornamenti su ambienti rappresentativi degli sviluppatori prima di una distribuzione estesa.

La compatibilità è un'altra preoccupazione continua. I fornitori di agenti di coding possono modificare schemi di configurazione, flussi di autenticazione, requisiti dei modelli o comportamento della CLI. Unity Gateway deve adattarsi abbastanza rapidamente da evitare che un aggiornamento centrale interrompa contemporaneamente tutti i client supportati.

Il repository pubblico contiene già segnalazioni riguardanti il supporto delle piattaforme e le combinazioni di fornitori. I singoli problemi non dimostrano che il prodotto sia ampiamente inaffidabile, ma illustrano l'onere di integrazione creato da un gateway multi-agente.

La centralizzazione può anche aumentare il raggio d'azione di un problema. Un'impostazione predefinita errata, una registrazione MCP non valida, un percorso di autenticazione scaduto o una policy eccessivamente restrittiva possono influenzare simultaneamente molti sviluppatori. Procedure di rollout per coorti e rollback sono essenziali, non semplici comodità opzionali.

Le organizzazioni dovrebbero separare tre affermazioni durante la valutazione. Unity Gateway può centralizzare configurazioni selezionate. Può governare il traffico instradato attraverso i suoi servizi. Può raccogliere evidenze dai client supportati. Nessuna di queste affermazioni significa che controlli ogni azione eseguita da ogni agente.

Un pilota credibile dovrebbe testare percorsi di aggiramento, comportamento degli strumenti locali, recupero dagli errori, conflitti di configurazione e completezza dell'audit. Dovrebbe inoltre confrontare i record del gateway con le fatture dei fornitori e la telemetria lato client.

Il modello di distribuzione più solido utilizzerà controlli a più livelli. Unity Gateway può fungere da confine per il traffico di modelli e strumenti. I controlli nativi degli agenti possono limitare l'esecuzione. I sistemi esistenti di distribuzione del software possono continuare ad applicare policy di revisione, test e rilascio.

Tre segnali mostreranno se la strategia del gateway funziona

Il prossimo test è stabilire se Databricks riesca a trasformare un'ampia compatibilità in un'adozione misurabile senza indebolire la copertura delle policy.

Il primo segnale è la parità di supporto tra agenti e fornitori. Gli acquirenti dovrebbero osservare se routing dei modelli, Smart Routing, registrazione MCP, skill, tracing e accesso a fornitori esterni diventino disponibili in modo coerente tra i client supportati.

Una maggiore parità rafforzerebbe l'argomento del piano di controllo condiviso. Eccezioni persistenti spingerebbero le aziende verso un'amministrazione specifica per agente o un'architettura mista. La configurazione solo MCP di Cursor e le attuali restrizioni dello Smart Routing forniscono chiari riferimenti per il confronto.

Il secondo segnale è rappresentato da prove indipendenti su costi e qualità. Databricks ha pubblicato un risultato di risparmio del 35% e una consistente stima interna sulla riduzione degli sprechi. I clienti devono ora riferire se il routing riduce il costo totale per attività dopo aver incluso tentativi ripetuti, revisione umana, latenza e chiamate a strumenti fallite.

Le prove di un costo inferiore per attività completata convaliderebbero il meccanismo di routing. Risparmi basati solo sui prezzi dei token sarebbero meno convincenti, perché richieste economiche possono comunque generare costose rilavorazioni ingegneristiche.

Il terzo segnale è la copertura della governance in produzione. Le aziende dovrebbero misurare quale quota delle chiamate ai modelli degli agenti e delle invocazioni degli strumenti compare nei record del gateway, quindi testare se le policy bloccano coerentemente gli accessi proibiti.

Un'elevata copertura con pochi aggiramenti sosterrebbe la tesi centrale di Databricks. Lacune persistenti tra sessioni gestite e native la indebolirebbero, soprattutto nelle organizzazioni in cui gli sviluppatori possono installare o avviare client al di fuori del percorso approvato.

La CLI Databricks Unity Gateway arriva in un momento utile. La scelta dei modelli si sta ampliando, gli agenti di coding stanno ottenendo un accesso più profondo e console separate dei fornitori non producono naturalmente un unico livello di policy per l'intera azienda.

Databricks ha proposto una risposta chiara: preservare l'interfaccia preferita dagli sviluppatori, ma rendere il gateway il punto di controllo duraturo. Questa risposta è più flessibile che costringere ogni ingegnere a usare un solo agente, ma più impegnativa che installare un'altra utility da riga di comando.

I responsabili di piattaforma dovrebbero ora avviare un progetto pilota circoscritto con due agenti, diverse classi di attività e test espliciti di aggiramento. Prima di estendere la distribuzione, confrontino il costo per attività completata, la copertura delle tracce, l'attrito per gli sviluppatori e i tempi di ripristino.

La domanda decisiva non è se ug codex o ug claude si avvii correttamente. È se un unico gateway possa governarli entrambi con una completezza sufficiente affinché la sicurezza si fidi delle registrazioni, la finanza si fidi dei dati di spesa e gli sviluppatori continuino a utilizzare il percorso approvato.