Vercel Labs UI SDK: Behaviors for Agents to Build Accessible Components

Vercel Labs published UI SDK, a beta library of UI behaviors that coding agents use to build components. The repository, vercel-labs/ui, was created on October 26, 2026 and has collected about 2,905 stars since. Its tagline is "A library of behaviors for agents to build the next generation of user interfaces."

The pitch is narrow and useful. Keyboard navigation, focus recovery, selection, dismissal, popups and drag and drop are the parts of a UI that agents often get subtly wrong. UI SDK moves that logic into a tested core, and asks the agent to wire it up instead of reinventing it.

We read the README and the npm registry entry for this post. We did not build a component with it in this unattended session, so every behavior below is as the maintainers describe it.

TL;DR: what UI SDK is and is not

Why would agents need a behavior library?

Ask a model for a combobox and you usually get something that looks right and breaks on the second keypress. Focus is lost when an item is removed. Escape closes the wrong layer. Screen readers hear nothing useful. These are behavior bugs, not styling bugs, and they hide until a keyboard or assistive-technology user hits them.

The usual fix is a headless library that owns the behavior while you own the look. UI SDK follows that idea but changes who the user is. The documentation and example are written so that an agent can read them, and the repository ships an AGENTS.md and a CLAUDE.md according to the page listing. Topics on the repo include agent, agents, mcp and webmcp.

That makes it part of a pattern Vercel has been building. Our coverage of Vercel's DESIGN.md spec showed the design side, where a spec file tells an agent what the UI should look like. UI SDK handles how the UI should behave. The Vercel Eve agent framework and the agent-desktop accessibility tree CLI point the same way: tools designed for agents as the primary reader.

How does UI SDK work? definePrimitive and createParts

The README's model has two steps.

Step 1: define a primitive. You call definePrimitive with a name, a state factory, an API and slots. Slots describe each part of the component, its attributes, its event handlers and which state decides whether it is present. The README example builds a search field with an input slot and a clear button slot. The clear button only appears when the value is not empty, and it uses createFocusRecovery so focus falls back to the input after the button disappears.

Step 2: render the parts. You call createParts from your framework's adapter and map slot names to elements. The README says "The parts are the same in all five," meaning React, Vue, Svelte, Solid and Web Components expose the same part names from the same primitive. For Web Components, you register a custom element per part.

Here is the install and skill setup, taken from the README:

npm install @ui-sdk/react @ui-sdk/core
npx skills add vercel-labs/ui --skill ui-sdk

The core idea is that one behavior definition carries across frameworks. If your team has a React app and a Svelte marketing site, the same agent-written search field logic can serve both. That claim comes from the README. We have not tested cross-framework parity.

Three differently shaped tiles fitting into a modular frame, showing how UI SDK behaviors snap into agent-built components

What is in the beta, and what is missing?

The npm entry for @ui-sdk/core lists the description "A library of behaviors to build your components. Made for agents." The latest and beta dist-tags both point to 0.1.0-beta.1. The package was created at about 17:05 UTC on November 12, 2026 and the homepage is ui-sdk.dev.

The README names these behaviors in text and in its header image: createPopup, createSelection, createTypeahead and createFocusRecovery. The README does not list every component, but the npm package's export map shows a wide set of per-component entry points, including menu, tabs, dialog, combobox, select, popover, tooltip, calendar and date-picker. These are unstyled behaviors, not a styled component gallery, so expect to build or generate the visible layer yourself.

The beta terms say the "framework, APIs, documentation, and behavior may change before general availability." Pin the version, do not build a production design system on it yet, and expect renames.

How should you try it with Claude Code or Codex?

Our agent skills guide explains why a skill is the right delivery format: the agent loads instructions only when it needs them. The ui-sdk skill is that kind of pack. A sensible trial looks like this.

1. Create a scratch branch in a small app. Do not start in your main design system.
2. Install the core and your adapter, then run the npx skills add command.
3. Ask the agent for one component with real behavior: a searchable select with clear button, or a dismissible popover.
4. Read the generated primitive. Check that it uses the core behaviors rather than hand-written key handlers.
5. Test with the keyboard alone, then with a screen reader. Do not trust the agent's claim that it is accessible.
6. Compare with how the agent does the same task without the skill. That gap is the real value of the library.

If you use design files, combine this with the approach in our DESIGN.md templates guide: the spec controls appearance, the behavior library controls interaction.

How does this compare with shadcn, Radix and other UI kits?

We name these categories in plain text because we have not compared output on the same tasks, and we will not claim UI SDK wins. What differs is the target: the README addresses the agent directly. That is a bet that more UI code will be written by models, and that models do better with small, composable, well-documented behaviors than with large components full of options.

The risk is the same as with any generated code. The more the agent writes, the more you must verify. A behavior library narrows what can go wrong, because focus and ARIA logic sit in code that humans wrote and tested, but the glue is still generated. For the wider question of reviewing what agents produce, see our guide to loop engineering for coding agents.

What should you check in agent-written primitives?

A behavior library does not remove review. It changes what you review. When an agent hands you a primitive built on UI SDK, check these points before you merge.

• Does each slot use a core behavior? If the agent wrote its own keydown handler for something the core already covers, such as selection or typeahead, ask it to use the shared behavior instead.
• Is focus handled when parts disappear? The README's clear button is the model case. When a part is removed from the page, focus must land somewhere sensible, which is what createFocusRecovery is for.
• Does state decide presence? The example uses a present function so the clear button only exists when there is text. Parts that are hidden with CSS but still in the tab order are a common agent mistake.
• Do all adapters get the same parts? If you target more than one framework, render the primitive in each and confirm the part names and attributes match.
• Is the version pinned? A beta that may rename APIs should never float on a caret range in a shared repository.

These checks take a few minutes per component. They are cheaper than finding a focus trap in production, and they are the same habit we recommend for any generated code.

What are people saying?

We found no Hacker News thread for the repository at the time of writing, and GitHub listed 6 open issues and pull requests combined. Public hands-on reports are missing. That is normal for a project that is under three weeks old, and it means the star count tells you about interest, not quality. If you test it, publish your findings, since there is little independent evidence yet.

What this means for what you build

If you build front ends with agents today, UI SDK is worth a one-hour trial because the failure it targets is real and costly. If you ship a design system to customers, wait for a stable release. The cost is zero dollars and the risk is churn.

Teams should also watch the adoption pattern: libraries that publish a skill, an AGENTS.md and an agent-focused README are treating the model as a first-class user. Expect more of them. Our React Server Components guide is a useful companion if your app is in Next.js and you want to know where behavior code should run.

Related reading

• Vercel DESIGN.md spec for AI UI
• Vercel Eve agent framework
• Vercel agent-desktop accessibility tree CLI
• What are agent skills?
• DESIGN.md templates for AI agents
• Loop engineering for coding agents
• React Server Components guide

Official sources: the vercel-labs/ui repository, the UI SDK docs, and the @ui-sdk/core npm package.

Version numbers, star counts and README details are accurate as of November 13, 2026. This is a beta and may change.