A design system AI agents can build with

Syntax is the design system behind Phrase's products. Getting a merged company to adopt it across three tech stacks took three years (Part 1). By early 2026, adoption was finally moving.

In March 2026, a two-week spike showed that an AI agent could build real, on-system UI if the system was written for it. In May, a reorganization cut design, engineering, and QA capacity. The work didn't shrink. It grew. What had been an experiment became the plan.

The system had to keep working without a designer in the room. More UI would be built by PMs, by developers working fast, and by AI agents. The only way to keep that UI on-system was to make the system readable by the things building it.

Building it surfaced a problem I hadn't expected. Our codebase was full of custom components the system never designed. Agents read the code around them and treated those components as permission.

I tested it. I asked an agent to add a button to a legacy screen full of hand-built buttons. Without our setup, it copied the hand-built style every time. With it, never. Three runs each, on prototypes, so a small sample, but every run went the same way.

Knowing the components isn't the hard part. Choosing is. The agent has to decide from whatever is in its context, "this is the right one" or "keep looking," so the real design problem was what to put in that context, and how much.

I chose a coding agent that works inside our repository, on our real Vue components, over tools that generate lookalikes. Then I went through three versions of what it reads before it picks.

The first, manifest-full.json, was a dump of every component and every prop in one file: expensive for the context, and not very effective. The second, manifest-compact.json, was a list of the components, loaded every time; for detail, the agent went back to the full manifest. The third is a curated index. It helps the agent choose with use when and avoid when, and says where each component's details live, including the design, accessibility, and content guidance the first two never had.

I judged each version by the output, by cost, and by a few tests. The deciding signal was the custom-component problem: whatever we built had to make agents reach for the system first.

The notes that made the difference were judgment calls: why this component and not that one, and when a variant stops being right.

That judgment used to live in people's heads. A junior engineer struggled with the same gaps an agent did. It wasn't an AI problem. It was a documentation problem AI happened to expose.

So the per-component notes grew beyond code: design choices, accessibility, and content guidance, each in a small file the agent loads only when it needs it. Along the way we found that most guidance pages had drifted from the code, and we reconciled them.

The system's users are people first.

On day one of the pilot, the first testers got stuck on setup, not on the design system. We fixed the guide that morning. Then we built a starter project, and rules that tell the agent its user may never have used a terminal.

From prototype to production. A PM was asked to redesign the sign-in and sign-up pages. They started from the starter project and had a first full page within a few hours. A designer shaped the directions. The front-end team then built the production feature from that prototype, on the same design-system components. About two weeks from first prototype to production.

The PM's verdict: smooth, but long build sessions got expensive. Within days, the design plugin had a skill that keeps long builds cheap.

That loop was the method. Collect where people stumble, change the system, and watch the next person not stumble there. Another PM's flow exposed copy that broke our content rules and rules the agent forgot, so we added content skills and made the rules enforced instead of advisory.

By October, a couple of dozen prototypes came from about fifteen people across design, product, and content, and at least two engineering teams had built production features from them.

The design plugin grew the same way: 26 small skills from six contributors. I built the plugin and the prototyping, docs, and audit skills; colleagues contributed the rest, including accessibility and content. Colleagues in other teams have built their own plugins on top of it.

The AI setup covers the component library, not the older toolkit products. For those, the agent has to guess, and the guesses show.

The agent exposed that gap instead of closing it. That turned out to be useful. It put a price on the compromise from Part 1 and gave a new argument for migrating those products.

As of October 2026:

• Per-component notes ship with the design system. The curated index is in review.
• Rules are enforced, not advisory: lint, edit-time reminders, and a docs lookup.
• New prototypes build with the system by default.
• An automatic check to keep guidance and code aligned is next.
• "Agent-ready design system" is company direction, with my spec as the reference.

None of this happens without the design-system engineers who built the pipelines, the content designer who wrote the content rules, and the PMs and designers who tested it before it was comfortable.

Progressive disclosure works for agents too. Show what's needed to decide, then reveal the detail. Load only what's relevant to the task. It's the oldest pattern in interface design, applied to a new kind of user.