Governing Coding Agents with ug
01 / 11

Navigation

→ / SpaceNext slide
←Previous slide
HomeFirst slide
EndLast slide
SwipeTouch navigation
Click anywhere or press Esc to close

Governing Coding Agents with ug

ug turns Unity Gateway from a manually configured integration into a standardized, governed, observable developer workflow for AI coding agents.

ug (formerly ucode) is the local CLI. Unity Gateway is the hosted gateway it points your agent at.

Companion to the ug quickstart in tool-governance.

The challenge

Teams adopt coding agents faster than they can govern them.

A team rolls out coding agents like Claude Code, Codex, Gemini CLI, and Cursor. By default each agent authenticates straight to an external model provider. Spend is uncontrolled, usage is invisible to the platform team, and provider keys spread across laptops and CI.

Why this happens

A coding agent talks directly to its model vendor out of the box. There is no shared point where identity, limits, and usage records live, so the platform team has nothing to attach a control to.

Where the gaps show up

Uncontrolled spend

No per-user or per-team ceiling. A looping agent can run for hours before anyone notices the invoice.

No central visibility

The platform team cannot see who called which model, how often, or at what cost.

Scattered credentials

Provider API keys copied into shells, dotfiles, and CI, each one a separate leak path.

Closing these gaps without slowing engineers down is the platform team's job. Routing the agent through the gateway is how you do it.

What it is

ug configures and launches a coding agent so its model calls route through Databricks.

What ug does

A local command that configures a supported coding agent and launches it so its model requests authenticate to the Databricks AI Gateway. Supported agents include Claude Code, Codex, Gemini CLI, OpenCode, Copilot CLI, Pi, and Cursor.

  • Handles OAuth and writes each agent's config automatically, so there is no manual endpoint, token, or environment-variable wiring.
  • Agents authenticate through Databricks workspace credentials and OAuth, so normal use needs no provider API keys.
  • One CLI configures and launches many agents consistently.

What ug is not

It is not the hosted gateway. Installing the CLI provisions no gateway infrastructure and grants no model access. Your administrator enables the gateway features and grants model access separately.

The names, kept straight
NameWhat it means
ugThe local command to set up and launch a supported coding agent.
ucodeThe older command name, kept as a backward-compatible alias. Use ug for new work.
unity-gatewayThe Python package that installs both commands.
Unity GatewayThe hosted gateway. Older material calls it UAIG, and the workspace sidebar still says AI Gateway.
How it connects

One authenticated path from your terminal to an authorized model.

uglocal setup and launcher
↓
configures and launches
Coding agentClaude Code or Codex
↓
authenticated model requests
Databricks AI Gatewayidentity · rate limits · usage monitoring · routing
↓
routes inference
Authorized model
A logical request path, not a network diagram. Local adapters can sit in the path depending on the agent. ug handles configuration and authentication; the gateway handles model access and routing.
Governance

What routing through the gateway gives the platform team.

Identity and permissions

Callers need EXECUTE on the Unity Catalog model service, plus USE CATALOG and USE SCHEMA. Controls apply at the model-service, user, or group level, not baked into a laptop.

Rate limits

Bound request velocity so a looping agent cannot consume unbounded capacity, and one team cannot starve another.

Usage tracking

Every call lands in system.ai_gateway.usage, and inference tables can capture request detail, so spend and volume attribute by user, team, and model.

Not automatic: guardrails and payload logging require configuration. Setup succeeding does not mean every control is on. Model governance here is permission, rate, and usage control; enable guardrails and logging deliberately.
Boundaries

Model governance is not tool governance.

Routing model traffic through a gateway is a real control, but it is a narrow one. Be precise about what it does not cover, or access degrades quietly.

Routing model traffic is not a sandbox

Sending an agent's model calls through the gateway does not confine its filesystem or network. Tool access is a separate, deliberate step (see the next slide), and even then Unity Catalog governs the tools, which is not the same as an OS-level sandbox.

Keep the layers distinct

Which model an agent may call, which tools it may invoke, and what its process may touch on disk are three separate controls. ug and the gateway cover the first two; sandboxing stays its own layer. See Custom MCP Principles and the Authorization pillar.

Read a usage record for what it is: it confirms a model round trip happened, not that every governance control fired.
Governed tool access

MCP servers and Skills, registered through ug and governed by Unity Catalog.

Model routing gets the agent a model. This is the separate, deliberate step that gets it governed tools, and the governance stays in Unity Catalog rather than in the agent.

MCP integration

ug mcp add registers governed Databricks MCP servers with a supported agent: SQL, Unity Catalog functions, AI Search, and external connections. The agent gains tool access that Unity Catalog governs.

# register a governed MCP server with the agent
ug mcp add

Unity Gateway Skills

Connect agents to governed Skills published in Unity Catalog, downloaded locally or loaded live through MCP, so the agent uses reviewed, versioned capabilities rather than ad hoc ones.

Secure token refresh

The local MCP proxy fetches a fresh OAuth token per request. That reduces expired-token interruptions during long sessions, and developers never hold or rotate credentials themselves.

The boundary still holds

MCP tool access is governed by Unity Catalog grants, not by an operating-system sandbox. Registering a tool decides what the agent may call, not what its process may touch on disk. Keep sandboxing as its own layer.

Cost control

Four levers, each solving a different cost problem.

Smart Routing

A task-aware router selects a capable, lower-cost model for each coding task. Use it for cost and quality selection rather than a fixed allocation.

Traffic splitting

Send configured percentages across destinations for a canary, an A/B comparison, or a gradual migration. Up to five destinations, totaling 100%.

Ordered fallbacks

Retry eligible failures such as 429 or 5xx down an ordered backup list, for availability when a destination fails. Retries follow the fallback order, not the split weights.

Unified visibility

system.ai_gateway.usage records spend, and its routing_information field records the split and fallback decisions behind each call. ug usage gives a spend summary across coding tools, and usage lands in one dashboard rather than per-vendor consoles.

Choosing a mechanism

What chooses the destination, and when to use each.

MechanismWhat chooses the destinationUse it for
Explicit --modelYou name one service, which can still route internally.Predictable service selection.
Traffic splittingYour configured percentages.Canary rollout, A/B testing, load distribution.
FallbacksA failure, followed by your ordered backup list.Availability when a destination fails.
Smart RoutingA task-aware router picks a capable, lower-cost model.Coding-task cost and quality selection.
Smart Routing scope: it currently selects only system.ai services, not your custom catalog services, and an administrator must enable it. The caller needs access to every candidate model, or routing reports a missing model.
The front-door pattern

Give callers a stable name; change routing behind it.

1
Create your own model service

A Unity Catalog service named catalog.schema.service, for example main.ai.coding_claude. Point every caller at that name.

2
Change destinations behind it

Set traffic splits and ordered fallbacks on the service. Adjust them without touching any client, since callers only know the service name.

3
Grant callers access

Grant EXECUTE on the service, plus USE CATALOG and USE SCHEMA. Callers use the service name, not Model A or Model B directly.

Point the agent at the service
# stable front-door name; routing changes behind it
ug claude --model main.ai.coding_claude
ug codex  --model main.ai.coding_openai

Verify before rollout

Send a harmless prompt through a separate test service and inspect system.ai_gateway.usage. The routing_information field shows the split or fallback decision. Validate across enough independent sessions, not one short session.

Check API compatibility first

Native Anthropic requests need a Claude-backed service; native OpenAI requests need an OpenAI-backed service. A routing rule does not translate one provider protocol into another.

Getting started

Three steps to route your first agent.

1
Install

uv tool install git+https://github.com/databricks/unity-gateway, then ug --version. uv tool isolates the CLI's Python dependencies.

2
Connect your workspace

Clear conflicting ANTHROPIC_* and OpenAI or Codex provider overrides first, then run ug configure --workspace https://YOUR-WORKSPACE-HOST --agents claude,codex and sign in as yourself.

3
Launch one agent

From your project directory, run ug claude or ug codex. A basic reply confirms a model round trip; your administrator can confirm the gateway usage record.

The rule of thumb

Choose a custom service for administrator-defined traffic policy. Choose Smart Routing for task-aware model selection. They solve different problems, so do not expect Smart Routing to honor a custom service's split.

Governance stays layered

The gateway governs model access, rate, and usage. Keep tool authorization, sandboxing, and data grants on their own layers.

Then

Register governed tools with ug mcp add, review spend with ug usage, and rerun ug configure to add agents or change routing. Full setup, routing configuration, and troubleshooting live in the ug quickstart under tool-governance.