Enterprises are putting coding agents on a leash. Databricks just shipped the harness.

Databricks shipped a CLI called ug that routes coding agents through its Unity Gateway, where administrators control which models and tools developers can use and see what they cost. The company is selling a simple tradeoff: standardize agent access on one governed path, or keep paying for fragmented model access, scattered policies, and unlogged spend.

This is documentation-based research; nothing here was installed or tested.

What shipped

The ug command installs from a GitHub repo and launches the developer's agent of choice, already configured. The supported agents are Claude Code, Codex, Gemini CLI, OpenCode, GitHub Copilot CLI, and Pi. Typing ug claude or ug codex starts that agent pointed at Unity Gateway instead of the developer's personal keys, with the organization's model selection, approved MCP servers, and skills already wired in.

The governance part is the point. Organizations can centrally configure models, MCP servers, skills, a default harness, and Smart Routing, and those settings apply at agent launch or roll out through mobile device management. A September merge on the public repo made this explicit: when a workspace publishes a managed coding-agent config, ug configure applies it to every enabled agent without prompting the developer. The admin dictates the setup.

Databricks also added coding-agent activity to Unity Gateway's unified tracing. Tools and skills the agent used now appear alongside model requests, inspectable in the platform's Govern section. And the CLI shows spend in the terminal, so cost becomes visible at the moment of use rather than in a finance report two weeks later.

The docs date the capability to September 22, 2026; press coverage of the announcement landed September 24. Nothing about the product contradicts that timeline.

Why now

Databricks' pitch, as reported by press covering the announcement, is that model turnover is the problem: a new frontier model roughly every five days, with GPT-6, Claude Opus 5.5, Gemini 3.8, and Grok 4.7 all landing in the six months before the announcement, plus open-weight contenders like Kimi K3, GLM-5, and DeepSeek V4.1. That turnover framing is Databricks' marketing, not an independent finding, but the underlying dynamic is real enough: swapping the model under every developer's personal API keys is a coordination problem, while swapping it once in a gateway config is an ops task.

Databricks is not alone in seeing this. Anthropic's own Claude Code changelog this month reads like a parallel governance project: managed settings for permissions, auto mode, worktrees, and attribution; admin-lockable boolean keys for connector features. And in this same week, Claude Code 2.1.280 moved the default model on Pro and Team Standard plans from Sonnet to Opus, meaning the model an employee uses can change under them without their input. The agents are getting more powerful and less predictable at the same time, and IT teams are reaching for the same answer datacenter admins reached for years ago: route the traffic through a proxy you control.

The decision this informs

If your organization has more than a couple of teams using coding agents across multiple model providers, a gateway is the standard answer. One place to set approved models, one place to enforce which MCP servers and skills are allowed, one log of who called what, and one lever to switch models when pricing changes (as it did repeatedly this month). The ug CLI exists precisely to make that lever one command instead of a per-developer config project.

Do not centralize because Databricks says models turn over every five days. Centralize because you have a concrete fragmentation problem: developers on personal API keys, tools you did not approve, no audit trail, and spend you cannot attribute. The gateway solves the concrete problem; the vendor's turnover story is just the sales deck.

And be honest about the bypass problem. A gateway only governs traffic that goes through it. Nothing in the docs stops a developer from opening the same agent with their own keys on the same laptop. The managed config flows and MDM rollout suggest Databricks knows this: the control plane works if IT actually owns the device config, not if the CLI is optional. Before committing, pilot with one team, make the gateway path the default in your managed config, and check the unified traces against your API invoices. If traffic shows up in the invoices that is not in the traces, you do not have governance; you have a suggestion.

What remains unknown

Nothing here was installed, configured, or tested, so setup friction, latency overhead, and policy enforcement in practice are all unverified. Adoption is unknown: this shipped days ago, and no customer deployments are public yet. Gateway pricing and whether Unity Gateway requires a Databricks workspace commitment beyond the gateway itself were not checked. The supported-agent list is broad (six agents, with Cursor Agent getting MCP-only support), but whether every policy control applies uniformly across all of them is undocumented. The model-turnover figures are Databricks' claims relayed by press. And the central open question is behavioral: how many developers route around the gateway, and does IT notice.