Databricks put agent skills in Unity Catalog, and gave them two names

On 28 August 2026 Databricks shipped a Beta that lets you publish an agent skill to Unity Catalog and share it the way you share a table. It solves a problem every team with more than two agent users already has, and it is hard to find written up anywhere, partly because Databricks has not settled on what to call it.

The problem it actually solves

Coding agents get good at your codebase through instructions you write: a runbook for the deploy, your team's SQL conventions, the way you want a table analysed. Those instructions live in files on someone's laptop. When they are useful, they get pasted into Slack, copied into three repos, and drift apart within a month. Nobody knows which copy is current, and a new joiner cannot discover that any of it exists.

The fix here is not another sync tool. A skill becomes a first-class Unity Catalog securable, addressed as catalog.schema.skill, governed by the same permissions, tags, and audit trail that protect your tables. Sharing is a grant, not a copy. There is nothing to keep in sync because there is only one of it.

First, the name, because you will search for the wrong one

This feature answers to several names, and the docs use two of them on the same page. As of 2 September 2026, the section is titled "Skills support in Unity Gateway" while its opening sentence reads "Unity Catalog Skills give you a central location to discover, publish, and govern agent skills across your organization". Both tutorials say Unity Gateway Skills. The URL path says uc-skills. The governance page sits somewhere else entirely, under /ai-gateway/, and points onward to Unity AI Gateway, which is the actual generally available product this sits inside.

They are all the same feature. This is churn rather than a settled split: the tutorials were retitled to Unity Gateway Skills on 1 September, one day before I checked, and Google's index still carries their previous Unity Catalog titles. The authoritative announcement, the 28 August release note, is headed "Unity Catalog Skills (Beta)", so if you are betting on where this lands, the release note and the URL both still say Unity Catalog. Search for both, and note that the surrounding product is Unity AI Gateway, which is what third-party coverage will use.

How the loop works

Three steps. Authoring and consuming run through your coding agent; the grant in the middle is an ordinary Catalog Explorer operation, which is rather the point.

1. Author. You develop a skill locally in the SKILL.md specification format, then publish it to a Unity Catalog schema. The tutorial asks for USE SCHEMA and CREATE VOLUME, but take the privileges from the governance page instead: authors also need WRITE VOLUME with READ VOLUME alongside it. Provision from the tutorial alone and your authors can publish a skill and then find they cannot update it.
2. Grant. Someone with ownership or MANAGE on the skill grants consumers USE CATALOG on the catalog, USE SCHEMA on the schema, and READ VOLUME on the skill, from Catalog Explorer. Skills keep their contents in Unity Catalog-managed storage, much like volumes, which is why the volume privileges are the ones you use.
3. Consume. A teammate's agent lists and loads the skill from the registry, leaving the same audit trail as any other Unity Catalog access.

The plumbing is a CLI called ucode, installed from source, which signs you into the workspace and registers a Databricks Skills MCP server named databricks-skill-registry with your agent. MCP, the Model Context Protocol, is the open standard agents use to connect to tools.

uv tool install git+https://github.com/databricks/ucode
ucode configure --agents <your-agent> --workspaces https://<workspace-host>
ucode configure skills

Supported agents at the time of writing are Claude, Codex, Gemini, opencode, and Copilot. You need Python 3.12 or above, uv, and a Unity Catalog-enabled workspace.

The decision you actually have to make

The overview says there are two ways to consume a published skill. The tutorial says three, and the tutorial is right.

• Load it once, for this session only, via the load_skill tool. Nothing is saved. Right for a one-off.
• Download it to disk so it loads every session and works offline. Right for the handful you use daily. Copies are point-in-time, so you re-download to get updates.
• Load a schema live, which scopes the MCP server to a whole schema so everything in it stays current with nothing stored locally. Right for a large, fast-moving set, and it needs a connection.

Downloading takes a --skill flag and accepts a comma-separated list, so it can be as narrow as one skill. Live loading cannot: the docs are explicit that it works on a whole schema at a time and cannot be scoped to a single skill.

Downloading also quietly reintroduces the drift this feature exists to remove, since a downloaded copy is a copy. That is a fine trade for a stable skill you want offline, and the wrong default for anything your platform team edits weekly.

Constraints worth knowing before you plan around it

The governance page carries the rules that decide whether this works in your account, and they are easy to miss because it sits under /ai-gateway/ rather than with the tutorials.

• The preview toggle is not called Skills. An account administrator has to enable the Unity AI preview from the account console Previews page before anyone in the account can create or use skills. Note the level: account, not workspace, which is a different conversation in most organisations.
• The schema has to be a real one. It must sit in a standard Unity Catalog catalog, not a foreign or federated one, and must resolve to a managed storage location, or skill creation simply fails.
• Compliance Security Profile workspaces cannot author. Where that profile is enforced, for example under HIPAA, creating, updating and deleting skills is blocked. Reading existing skills still works. If your regulated workspace is exactly where you wanted governed runbooks, read that line twice.
• Reach follows the metastore. Skills are only reachable from workspaces assigned to the metastore holding them, the same rule as the rest of your Unity Catalog data.
• It is Beta. Databricks Beta carries no service level agreement and no formal support, and is not intended for production. That is worth weighing against the instinct to put your deploy runbook behind it on day one.

The ucode tool also installs from a Git source rather than from PyPI, which is normal for a Beta and worth flagging to whoever approves what runs on engineer laptops.

Why this is more interesting than it looks

Most agent tooling treats prompts and instructions as personal configuration, which is why every team ends up with five versions of the same runbook. Making a skill a governed catalog object says something different: that the way your organisation does a task is an asset with an owner, permissions, and an audit trail, sitting in the same catalog as the data the task touches.

If that holds up, the interesting question stops being which agent you use and becomes who is allowed to publish the instructions everyone's agent follows. That is a governance question, and Databricks has made it answerable with a grant. The irony worth watching is that the workspaces with the strictest governance, the ones enforcing the Compliance Security Profile, are currently the ones that cannot author skills at all.

Checked against the Databricks documentation on 2 September 2026, five days after the Beta was announced. Beta features move quickly, and the naming here is visibly unsettled, so verify before you build on it. brickster.ai is an independent community project and is not affiliated with Databricks.