Agents Read the Design System. Read Is Not Checked.

Luke Wroblewski ended a post on October 1 with a sentence design systems people will be quoting for a year. "Design teams have spent years trying to get people to actually read their design system documentation. Agents read it every single time."

The reader showed up. I don't think reading was ever the control.

The short version

Luke Wroblewski describes a design system for AI agents as a steering layer: an AGENTS.md file that tells agents to reuse the site's tokens and components, plus a design system page built from the same code. Figma's Wayne Lin published the upkeep side five days later, an agent that audits screens against the library. Both treat the agent as a reader. Reading is not following. Vercel's inbound sales agent read a 1,000-line prompt on every run and stopped following some of the rules in it, per Jeanne DeWitt Grosser in Tomasz Tunguz's write-up, and 14 rules moved into code. A design system for agents needs the same split, made on purpose by design. Write each line as a constraint with a failure condition and a check. Machine-checkable lines go in the pipeline, judgment lines get a named reviewer, and the rest gets cut. Then count one number: how many lines in the file have a checker.

What the two posts say

I read both in full.

Wroblewski's argument starts from a pattern he has watched for twenty years. A team invests in a design system, the product moves, and the system ends up describing a product that no longer exists. His fix is to make the system part of what he calls the AI steering layer. When marketing, engineering, and a PM can each have an agent update the site, a design lead and a front-end lead define the grid, fonts, colors, spacing, and components once, and everyone's agents are "snapped to" it.

His example is concrete. On the Intent website, an AGENTS.md file tells agents to reuse the theme classes and CSS variables in the global stylesheet instead of duplicating values. The stylesheet holds the design tokens. A design system page shows it all as live examples, and it stays current because it is built from the same code as the site. Ask an agent for a new button and it reuses the Button component, dark mode included.

Wayne Lin's Figma post on October 6 comes at it from maintenance. The Figma agent can inventory the components and tokens on a screen and map them to their libraries. His example: a designer builds a "Save for later" button from scratch, and the agent flags that it duplicates the system's Button/Secondary component and uses a hard-coded color instead of the token. It can reconcile names that drifted, hover, hovered, and mouse-over. And a team can attach guidelines to a published library so the agent gets the intent and rules without anyone retyping them in a prompt.

Good work, both. And both describe an agent that reads.

Read is not followed

Here is the sentence I'd put next to Wroblewski's. It is from Jeanne DeWitt Grosser, Vercel's COO, in Tomasz Tunguz's account of how their inbound sales agent was built. The prompt started at about 125 lines and grew to 1,000. Then:

"The model actually won't always follow some of the rules that are embedded in that prompt."

Vercel's answer was to take the parts that were really rules out of the prompt. Inbound runs on 14 rules in code now, and the model keeps the judgment. I wrote about the second half of that design in Fourteen Rules, and Who Blesses the Exception.

That agent read its instructions every single time too.

What I see in teams copying the steering-layer idea is that they write the agent-facing design system the way they wrote the human one. In prose. Use the brand voice. Prefer existing components. Keep spacing consistent. Those are principles, and my complaint about principles is rule 1 in Design Just Got Promoted: a principle has no failure condition. "Delightful, human, trustworthy" has never once stopped anyone from shipping anything. An agent can read "keep spacing consistent" ten thousand times and nobody can tell you how often it didn't.

Wroblewski's own example is the strong case, and it's worth seeing why. "Reuse the CSS variables instead of duplicating values" has a failure you can observe. A hard-coded hex value in a diff is right there. The design system page can't go stale because it is generated from the code. The lines that work in his setup are the ones with a mechanism under them.

Three piles

In the Design Operating Model a constraint is a rule with a failure condition attached, so you can tell when it was broken. The worksheet that ships with chapter 1 lists each rule with its failure condition and its check. The check is a person, a reviewer, or an eval. It is also the part an agent-facing design system usually leaves out.

Take the agent-facing design system, AGENTS.md or the library guidelines or whatever you call yours, and sort every line.

1. A machine can catch it. Rewrite it with the failure condition and put the check in the pipeline. "Reuse the color tokens" becomes: no hard-coded color value in a diff. Broken when a hex code appears outside the stylesheet. Checked by a lint on every pull request. Figma's audit belongs here too, on the design side. In Lin's post it runs when a designer asks, and he notes a team can package a check as a skill to run it regularly. Do that.
2. A person has to judge it. Tone. Whether this screen needed a new component at all. Name the reviewer and the moment in the process when they look. A sample is fine. A named person is not optional.
3. Neither. Cut it. Every line that can't be checked dilutes the ones that can, for an agent as much as for a person. Vercel found the limit at 1,000 lines. I wouldn't go looking for yours.

One caution on the word "once." A design lead and a front-end lead define the system once, in Wroblewski's telling. The tokens will stay current because the page is built from the code. The rules won't, unless changing one is cheap. If updating a rule costs a meeting with the two people who defined it, the rules stop getting updated, and the file starts describing a product that no longer exists. That is the same failure Wroblewski opens his post with. It just moves from the component library to the rules file.

Who does this

The design systems team, and it is a bigger job than the one they had. Design's Kill List has the component library as monument on it, replaced by a constraint layer and a much smaller set of primitives, with the systems team owning the constraints and the checks. The same list retires the end-of-cycle design QA pass in favor of constraints checked automatically. The steering layer is that constraint layer with a new reader, and somebody on the team has to be able to write the lint.

The number I'd ask for is small. Of the lines in your agent-facing design system, how many have a checker?

It's part of the running argument on AI Product Management. AI collapsed the cost of the part of the job people were trained for, which here is producing the system, and left the part nobody trained for, which is enforcing it.

One thing to try this week: open your AGENTS.md or your library guidelines and mark each line M, P, or nothing. Machine, person, or no checker. Count the nothings.

Related answer: How do you write a design system for AI agents?

Sources: Luke Wroblewski, "Design Systems for AI Agents," LukeW, October 1, 2026. Wayne Lin, "How to lighten design system upkeep with the Figma agent," Figma Blog, October 6, 2026. Tomasz Tunguz, "How to Automate Inbound," October 6, 2026, with Jeanne DeWitt Grosser quoted. Design Just Got Promoted and Design's Kill List, The Design Operating Model, falkster.com.