A design system used to have one audience: the people building the product. Now it has a second one, the AI agents writing screens and code with it. They read it differently, and they don't ask questions when something is unclear.
Name things for what they mean
An agent can't guess that gray-500 is the colour for secondary text. It can read text-muted. Semantic names turn a palette into instructions: what a value is for, not what it looks like.
The same goes for components. A Button with a variant="destructive" says more than a red button that someone remembers to use for deletions.
Write the rules down
The designer in the next room used to be the documentation. An agent doesn't have one. When to use a component, when not to, what it should never be combined with: those rules need to live next to the component, in plain words.
Keep components predictable
Few variants, the same prop names across components, no one-off overrides. Every exception is something an agent will get wrong at least once.
Test it with an agent
Give an agent a real task with your system, like building a settings page, and read what comes back. Every mistake is a gap in the documentation, not in the agent.
What I've seen in practice
[To write]Concrete examples from your client work: what broke when an agent used the system, and what you changed.