Design systems were written for people. Agents need rules.

Think about who writes the interface code in your product today. A year ago, the answer was your engineers and designers. Increasingly, it's an agent: Cursor, Claude Code, Copilot, v0, Lovable, working from a prompt someone typed in a few seconds.

Now think about whether that agent has read your design system. In most teams I talk to, it hasn't. It might have access to the component library, because the components are in the codebase. But the reasoning behind them, the rules about when to use what, the voice, the things you never do: none of that reaches it.

Design systems were written for people. People read documentation, absorb it over months, and ask a colleague when they're unsure. Agents do none of that. They work from whatever is in their context at the moment they're asked, and they forget it as soon as the task ends.

The context window is the new style guide

There's a shift happening across AI tooling that designers should pay attention to. Engineers have started calling it context engineering: the practice of deciding what an agent sees before it acts. Rules files in the repo, project instructions, retrieved documents, tool definitions. Much of the quality difference between a good and a bad agent result now comes down to what was put in front of it.

For code, teams have adapted quickly. Repositories now commonly carry instruction files for agents, describing conventions, test commands and patterns to avoid. For design, almost nobody has done the equivalent. The agent building your settings page knows your lint rules and nothing about your design principles.

That's a design leadership problem, and it's a very fixable one.

What machine-readable actually means

A design rule an agent can use has three properties.

It's specific. Keep it clean is not a rule an agent can follow, or one you can check. No more than one primary button per screen is. Most design guidance is written as aspiration. Agent-ready guidance is written as constraint.

It's checkable. If you can't tell whether a page passes, neither can the agent. Every rule should imply a test, even if that test needs judgement. This is the same discipline as writing a good acceptance criterion.

It's available at the right moment. A rule in a Notion page the agent never sees has no effect. The rule needs to be in the agent's context when it builds, and in the evaluator's context when it checks.

The third property is where protocols matter.

Rules over MCP

The Model Context Protocol is an open standard, introduced by Anthropic in late 2024 and now supported by most coding agents, for connecting an agent to outside tools and data. It's the reason an agent in your editor can query a database, read a ticket or call an API without custom glue for each one.

In Glitterball, the rules are served over MCP. Before an agent builds, it can call get_design_rules and get the exact rules that are switched on: the accessibility pack, the usability heuristics, the anti-slop packs and your own house rules, in plain language. After you scan the prototype, it can call get_suggestions and get back every failure as a specific fix, with the selector of each element. When it's done, it marks each suggestion as fixed.

That closes a loop that's been open for as long as design reviews have existed. The rules the work is judged by are the same rules the work is built from, and the feedback goes straight to whatever is doing the building.

One source, two uses

The thing I find most interesting about this is that one set of rules does two jobs.

Before the build, the rules are guidance. They narrow what the agent produces, so the first draft is already aiming at your standard instead of at the average of the internet.

After the build, the same rules are tests. They tell you, and the agent, what was missed.

In traditional design systems, these were separate artifacts. The guidelines said what to do. The review, run by a person, checked whether it was done. When the guideline and the check are the same text, they can't drift apart. Change a rule, and both the guidance and the test change with it.

What I'd do this quarter

If you lead a design system or a design team, here's a practical start:

1. List the twenty things your best reviewer says most often. These are your first rules. Write each as a constraint that can be checked.
2. Sort them into rules that can be measured (sizes, ratios, counts, banned words) and rules that need judgement.
3. Put them where agents look. At minimum, a rules file in each product repo. Better, served from one place over MCP so every agent and every evaluator reads the same version.
4. Run them on real work. Pick a recent feature and score it. Rules that fail good work need rewriting. Bad work that passes means you're missing a rule.
5. Make the rules part of the system. Version them, review changes to them, and give them an owner, like you would a component.

None of this replaces a design system's components, tokens or documentation. It adds a layer that was always implied but never written down: the judgement. Until now, that layer lived in people. It needs to live somewhere the agents can reach it too.

In the last piece of this series, I'll look at what that means for the people, and for the job of leading a design team.