Your design system isn't agent-readable. Astryx shows what is

My agent kept making the same clean dashboard. Different prompt, same blue tint, same 16px radius, same thin icons it thought I wanted. I wrote that design taste infrastructure is the missing AI stack — a file of tokens agents can read — and this week Meta shipped the reference implementation. It doesn't add another chat wrapper. It turns the design system itself into the interface agents use.

Your design system isn't agent-readable until your tokens, components, and docs are consumable by a CLI and an MCP — and Astryx is the first mainstream proof that this is how you stop AI-generated drift.

Why did Meta open-source a design system built for agents?

Because agents became the primary UI builder and most systems weren't built for them.

On September 13, Meta released the beta of InfoQ's coverage of Meta open-sourcing Astryx as an agent-ready React design system after eight years inside the company. The pitch in Meta's announcement introducing Astryx as an agent-ready system is plain: 150+ accessible components on React 19 and StyleX, seven themes, and templates — but the differentiator is that it is built for people and agents from the same reference.

Inside Meta it powers 13,000+ apps. Roughly half of updates came from the builder community itself. That history matters. This isn't a component marketing drop. It's a system that survived the edge cases of internal tools — tables, pickers, forms, sheets — and was then rebuilt so an agent doesn't have to scrape a docsite to use it.

The signal for solo founders is timing. Vercel collapsed compute and model routing last week. Astryx collapses the other side: how the interface itself is consumed. When your agent writes UI, it works best with typed props, predictable naming, and pre-compiled CSS it can import — not with a vague style guide PDF.

What makes a design system agent-readable in practice?

Three concrete choices: structured CLI docs, an MCP server, and tokens as the source of truth.

First, the CLI. Astryx ships @astryxdesign/cli with commands like astryx template --list, astryx component --list, and astryx component <name>. One command — npx @astryxdesign/cli init --features agents — generates an AGENTS.md that teaches the agent the workflow: find a template, study its skeleton, then read props for every component used. It also adds behavioral rules: no raw divs, no style={{}}, use tokens not magic values.

Second, the MCP server. The Astryx GitHub repository with 150+ components and CLI tooling exposes a Model Context Protocol server with two tools — search(query) and get(name). Any MCP-compatible tool — Claude Desktop, Cursor, Windsurf — can discover a component by natural language and pull full docs, props, and examples on demand. No pasted docs, no web search, no hallucinated props.

Third, tokens over prompts. Astryx decouples behavior and accessibility from aesthetic representation. Color palettes, type hierarchies, and radii live in a central token layer. You import pre-built CSS, keep className for interop with Tailwind, or eject via swizzle when you truly need private state. The agent doesn't invent a radius. It reads it.

I tried the docs quiz on the Astryx guide to working with AI through CLI and MCP. Three questions about props and theming have a 0% pass rate without the generated docs. Models guess confidently and wrong. With the docs, they follow the same reference you do. That's the test for your own system: can an agent answer correctly without you in the room?

Why does token drift still break AI-built products?

Because generation without a contract guarantees drift.

Each prompt builds one screen well. Nothing checks if the next screen belongs to the same product. The model optimizes locally, picks the median, and you get a landing with 12px radius, a settings page with 16px, and a dashboard with a shadow you banned last month. I’ve called this design drift is the tax AI charges on generated UI — twelve screens that each look fine alone and feel anonymous together.

Astryx’s v0.6.0 release shows how a system fights that. On September 10, the team shipped responsive theme rules and an adaptive Selector that renders as a bottom sheet on a compact surface and a popover on a wide one — same options, same value, different presentation by surface. Underneath, the team is writing durable specifications that define what a component owns: API, behavior, accessibility, anatomy, and theme targets. Once a spec is marked current, agents can verify against it and catch drift in tests and docs.

That’s the move solo founders copy: a contract the agent can check. Not a style tip. A file that says what truth is, and a check that fails when the output breaks it. Without that, you’re re-briefing taste every session and wondering why nothing holds.

How do you make your own system agent-readable this week?

You don’t need to adopt Astryx to copy its pattern.

Pick one repo and do four things before Friday:

• Write the token file. Palette, type scale, spacing, radius, and two forbidden moves. One page in DESIGN.md at the root. Not “be premium” — “12px radius on cards, 8px grid, muted palette, no neon, no centered hero on every page.”
• Generate the agent docs. If you use Astryx, run npx @astryxdesign/cli init --features agents and commit the AGENTS.md. If you don’t, write your own equivalent: component index, naming rules, and “no raw divs, no inline styles, use tokens.”
• Add the MCP or CLI check to your prompt. Tell the agent to run astryx component --list --dense or read your token file before it writes UI. Verify it actually did — the output should name tokens, not invent hex values.
• Review against the last two screens, not alone. Screenshot the new page next to the last shipped page. Ask: does this belong? Check radius, density, and hierarchy. Fix one drift per ship and add the rule to the file.

You don’t need more taste tools. You need one readable file and a system that enforces it the way Astryx does. The rest is holding that line while the model tries to average you back to the middle.