A Databricks lançou uma ferramenta de linha de comando que permite que administradores controlem quais agentes de código, modelos e ferramentas milhares de desenvolvedores podem usar, enquanto os desenvolvedores continuam iniciando seu agente preferido com um único comando. O Unity Gateway CLI, anunciado no blog da Databricks, fica entre a frota de agentes de código que uma organização de engenharia realmente executa e os provedores de modelos por trás deles, aplicando configurações publicadas centralmente no momento em que um desenvolvedor digita um comando como `ug claude` ou `ug codex`.
A mecânica é direta: administradores configuram padrões de agentes, servidores MCP, skills, Smart Routing e políticas de gastos em um só lugar, dentro da tela Govern → Agent Configuration do Unity Gateway. Depois que essa configuração é publicada, o CLI cuida da autenticação, conecta o agente escolhido ao Unity Gateway e aplica as configurações publicadas antes de abrir a interface normal do agente. Os desenvolvedores não configuram cada agente separadamente, e não precisam escolher um modelo por tarefa — o Unity Gateway faz o roteamento de modelo-ferramenta de forma centralizada, e as organizações podem distribuir o `ug` por meio de gerenciamento de dispositivos para que todo desenvolvedor comece a partir da mesma base bloqueada e aprovada.
O Smart Routing é a peça que faz o trabalho de custo por trás dos panos: ele equipara o custo do modelo à complexidade da tarefa, enviando trabalhos mais simples para modelos mais baratos e trabalhos mais difíceis para modelos mais capazes, e pode tomar decisões de roteamento separadas para uma sessão principal em comparação com um subagente delegado. A própria avaliação publicada pela Databricks sobre o Smart Routing relata 35% de economia de custos em seu benchmark interno de codificação. Os padrões sensíveis a orçamento estendem a mesma lógica aos gastos — quando o uso ultrapassa limites definidos, o Unity Gateway recomenda agentes e modelos de menor custo como o novo padrão para inicializações futuras, sem interromper os agentes já em execução. Os desenvolvedores podem verificar seus próprios gastos em relação ao orçamento restante com `ug usage`.
Os números operacionais citados pela Databricks vêm de duas fontes: um cliente e sua própria organização de engenharia. John Xing, Chief Technology Officer da Concurrence, diz que, desde a implantação do Unity Gateway CLI, "nossos agentes de código geraram mais de 61 bilhões de tokens de entrada em cerca de 360,000 requisições, com visibilidade centralizada sobre uso e gastos." Separadamente, a Databricks afirma ter usado o recurso de tracing do Unity Gateway junto com o Genie para encontrar e corrigir sete bugs de ferramentas MCP, um exercício que estima ter economizado $1.2 milhões por ano em gastos desperdiçados com IA e perda de produtividade. O tracing captura chamadas de ferramentas locais e invocações de skills dos agentes de código e as exporta para o que a Databricks chama de tabela de rastreamento unificada do lakehouse, onde o Genie é usado para identificar falhas repetidas de ferramentas e respostas superdimensionadas.
O que chama atenção pela ausência no post da Databricks são dados de latência, o preço por token do próprio gateway, ou qualquer detalhamento do que o número de 35% de economia do Smart Routing pressupõe em termos de combinação de tarefas — ele é apresentado como um único resultado de benchmark, não como uma faixa entre tipos de carga de trabalho. A empresa também não divulga como os sete bugs de ferramentas MCP se distribuíram entre os agentes, nem quanto do valor de $1.2 milhões corresponde a gastos versus produtividade, deixando essa estimativa como um número combinado, e não auditável. Equipes que avaliarem isso vão querer seus próprios dados de tracing antes de confiar em uma porcentagem de economia divulgada pelo fornecedor em relação à sua própria carga de trabalho.
A troca mais difícil é arquitetural, não financeira: centralizar o controle de modelo, ferramenta e política por meio de um único gateway é exatamente o tipo de gargalo que torna a governança possível e também transforma o próprio gateway em uma nova dependência e um novo salto de latência entre cada desenvolvedor e cada agente que ele executa. Travar as configurações no nível de gerenciamento de dispositivos resolve o problema de "acesso e controles de orçamento dispersos" que a Databricks descreve em seu próprio enquadramento do aperto entre padronizar em um único provedor e dar suporte a vários — mas também significa que qualquer interrupção ou configuração incorreta na camada do Unity Gateway agora afeta todos os agentes de código da frota simultaneamente, não apenas uma integração.
Para equipes que executam agentes de código em mais de um provedor, a medida prática desta semana é separar a camada de política da camada de agentes agora, antes que o tamanho da frota torne essa separação cara de implementar depois — um único caminho de roteamento governado só é uma vantagem se as decisões de roteamento forem inspecionadas, não apenas confiadas em 35%.