Making design systems work for AI

In my first article, I described a design system as a shared contract between design and engineering. I’ve also been working on how AI finds and uses that agreement as the guidelines grow.

For LootRate (opens in a new tab), a monetization consultancy I founded for live-service games, I’ve built a system I call “AI Core” that guides website work and branded assets, including PDFs and LinkedIn images. It includes shared components, tokens, and instructions for using them. I stopped having to repeat a lot of what the branding should look like, but the more guidance I added, the more I saw where it needed help.

Where the system fell short

I remember this most clearly with creating images for my LinkedIn posts. I talk about pricing and the elements that make monetization in gaming possible, and those ideas need different ways of being shown. The colors and logo should have remained, but the visual treatments started feeling limited by what we’d already created.

Sometimes the agent treated guideline files as “feature complete” and pushed back when I wanted to add to them or try a new approach. I had to try different prompts and explain why the system needed room to grow. I don’t know how much came from my instructions or their interpretation.

Finding the guidance was another issue. In a fresh chat, I sometimes still had to point the agent toward the system. I would normally have to call something a deliverable for it to find the PDF guidelines. The information existed, but using it still depended on how I asked.

Some decisions also appear in several documents, giving them opportunities to fall out of sync. And honestly, I’m not always looking at every individual file AI creates. That’s a tradeoff of working this way. Reviewing the result doesn’t necessarily tell me whether it used an existing component or created another implementation that we’ll have to maintain.

Finding guidance as it grows

One approach I think may help as systems get bigger is pathing. A starting document points toward the relevant area, where an index helps the agent find the detailed guidance. It can follow the task into the system without reading everything each time.

Here’s a simplified routing example based on my AI Core folders. The arrows show which documents to consult.

Starting instructions

website/

_index.md

• design-system.md
• design-token-system.md

deliverables/

_index.md

• pencil/pencil-style-guide.md
• Other format guides

For a designed PDF, the deliverables index should lead to the applicable guide. A website task follows a different route. Both still need access to the shared brand decisions that apply to their work.

BILL’s team found that providing documentation tools wasn’t enough to change agent behavior. It also had to make the workflow for consulting them explicit.¹ That gives me a useful improvement to make in my starting instructions.

Building on what’s available

For shared values such as colors and spacing, I’d like to revisit how the tokens are represented. The Design Tokens Community Group’s format provides a way to exchange token values, types, descriptions, and references between tools.²

I’d compare a small set of LootRate’s tokens with that format to see whether it could reduce the custom translation between tools while carrying descriptions of what the values are for. We’d still need guidance on how to apply those decisions.

The LootRate website already has shared components whose styles, variants, and sizes come from a central token module. An agent needs to know how to use those components as well as which values are approved.

Atlassian found a portable DESIGN.md useful for communicating visual direction in prototypes, while its richer tooling worked better for using existing components in its production environment. The authors describe those findings as dependent on the setting.³ I’d use that distinction when deciding what guidance each kind of work needs.

Keeping that guidance current matters too. BILL describes outdated documentation leading agents toward deprecated component APIs, and ties its documentation updates to changes in the components.¹

Atlassian’s CLI, agent tools, and reference files use shared underlying content and logic, so changes can reach each interface without separately maintained copies.⁴ I’d apply that principle to LootRate’s website and deliverables: maintain shared brand decisions once, with separate guidance where print and screen need different treatment.

Making the guidance work in practice

To address the rigidity I experienced, I’d make the scope of each instruction clearer. A brand color may apply everywhere, while a layout example may simply show what worked for one task. The agent should understand where it can explore and when it needs approval to change something shared.

I’d use the same website change, PDF request, and brief for a new visual treatment before and after revising the guidance. I’d start each in a fresh chat, without supplying folder names, to see whether the agent finds the right guidance and applies it appropriately.

Atlassian’s CLI team read agent transcripts alongside evaluating results.⁴ I’d like to do that too, so I can see which guidance was consulted and whether existing components were used where they fit.

Automated checks could help catch specific implementation problems. Reviewing the output would tell me whether it communicates the idea and works for its audience. I’d also look for unnecessary refusals or repeated explanations about where the agent can explore.

Whether I’m developing LootRate’s system or working with a new team, I’d want to see whether these changes reduce how much explaining I have to do in a fresh chat. For the LinkedIn images, I’d also want the agent to help find a better way to show the idea while keeping the brand recognizable.

In part three, I’ll look at what happens to consistency as AI makes it easier to create variations, and how teams decide which changes belong in the shared system.

References

1. David Cai, “How We Made Our Design System Bilingual: One Source of Truth for Humans and AI Agents” (opens in a new tab), BILL, August 17, 2026.

2. Design Tokens Community Group, “Design Tokens Format Module 2025.10” (opens in a new tab), October 28, 2025. Published through a W3C Community Group; the specification states that it is not a W3C Standard or on the W3C Standards Track.

3. Kylor Hall and Andrew Campbell, “Atlassian’s DESIGN.md is here: what we learned testing portable design context in practice” (opens in a new tab), June 15, 2026.

4. Sudharsanam Narasimhan, Kylor Hall, and Michael Abrahamian, “Giving AI agents design system context from the terminal: what we learned building a CLI” (opens in a new tab), September 16, 2026.