← Back

Case study · 001

SBT Design Ecosystem

An AI agent ships every design change straight to production. End-to-end infrastructure: Figma API, append-only registry, typed MCP tool surface.

01 · The problem

The handoff is the slowest step in the system.

A designer changes a button's hover colour on Tuesday. By Friday, production still shows the old value.

Nothing is broken; everything is slow. The change sits in a Slack thread, a Figma comment, a half-written ticket and an unpushed branch. This is where most design systems lose ground.

A handoff is a translation step. It does not need to be done by a person.

02 · The premise

Only the agent writes the code.

The core rule of the repo is simple: never edit the components folder by hand. Manual edits are overwritten on the next sync and break the link between Figma and code.

Every colour, radius, spacing and type value in production must trace back to a Figma variable. No local patches.

For that rule to hold day to day, the system has to do the work people used to do.

03 · The architecture

Four layers, one source of truth.

  1. Figma Source of truth. Components, variants, tokens.
  2. Nexus + Supabase Lint gate and append-only registry.
  3. MCP 36 typed tools. The agent's only interface.
  4. GitHub + Vercel React repo and live multi-brand showcase.

Nexus is the gate between Figma and the registry. It is a custom Figma plugin that rejects any component that is not fully tokenised and documented before it can be published.

Supabase is the registry. Six append-only tables hold every component, version and token. A two-phase lifecycle keeps drafts (0.x.x) separate from stable versions and promotes them exactly once with ds_publish_version to v1.0.0.

The MCP server is the agent's interface to everything else. Whatever the agent does, it does through this server. Nothing else has write access.

04 · The interface

Three commands, one conversation.

Designers and engineers don't open the registry or the React code. They talk to the agent. Three slash commands cover a component's full lifecycle.

05 · A day in the system

From a colour change to a live deploy.

A designer changes a button's hover colour from #2D8CFF to a darker blue. Step by step:

  1. Tue 09:42 Designer changes the hover blue and hits Publish in Nexus.
  2. Tue 09:42 Nexus blocks the publish. The new value is hardcoded, not bound to a token.
  3. Tue 09:43 Designer binds it to color/action/primary/600, adds "Darker hover for AAA contrast" to the changelog, retries.
  4. Tue 09:43 Nexus hashes the snapshot, exports a preview, writes the new version to Supabase, fires repository_dispatch to GitHub.
  5. Tue 14:11 Engineer types /cmp-update Button.
  6. Tue 14:11 MCP returns a delta. One token change, severity patch. The agent edits a single line of Button.tsx.
  7. Tue 14:12 /cmp-document refreshes the description. /repo-deploy pushes. Vercel rebuilds.
  8. Tue 14:15 New version appears in the showcase sidebar with its changelog attached.
Total time: about four minutes, most of it waiting for Vercel.

06 · Outcome

The system handles the follow-up.

The point is not the four-minute deploy. It is that no one in the middle has to remember the change, copy the value and reconcile two files.

Before A change lives in five places. Slack thread, Figma comment, half-written ticket, designer's notes, an unpushed branch. Token drift between Figma and production keeps growing.
After A change lives in one registry. Both layers read from Supabase. Token drift trends to zero. The agent handles the follow-up, the diff and the deploy.

Designers spend less time chasing implementations and more time shaping the system itself. Engineers no longer reverse-engineer design decisions from screenshots.

The team's role shifts: less translation, more architecture.