When agents build the UI, the design system has to speak to them too

Design systems were written for people, but agents now build much of GitHub's UI. In my second week I watched Copilot ignore Primer's tokens unless I named every one, so the system's intent wasn't reaching what agents actually produced. Scenario patterns fixed that for both agents and humans. For example, if you ask an agent to "add a way to delete this", a lot of the time it builds something plausible that ignores the system and is inaccessible. This improved the accuracy between intent and action.


I joined when Matt just shipped batch 1, and for the next three weeks I set out to close these gaps in batch 2, specifically the ‘delegate’ pattern’. It sits under GitHub's Agentic Quality Framework. An agent surveys every real implementation of a pattern, a designer turns that into evidence and guidance for UX principles, and reviewed by an external tetralogical accessibility team. The page is published for people, as llms.txt, and throughout primer’s MCP tool, so that agents read it before they generate.

Things to keep in mind

Reasoning

The main reader of a design system is becoming a machine. Now agents solely build a real but inconsistent screen. Generative tools don't generally create new UX failures, they industrialize old ones. So, guidance for accuracy becomes significant

Goal

Let humans and agents design from guidance they can fetch accurately, trust, and act on. That way a person's intent is met quickly, with accessibility, design, and Primer usage all covered

Dynamics

Pages must be short, since they compete with the user's prompt for context. A lot of testing QA for batch 1 pointed to that


Wrong recommendation published in the design system spreads to every team and agent.


No evaluator existed to prove agents follow the guidance


The act of ‘delegating’, ‘editing’ started to overlap with each other. Categorizing implementations is blurrier

Context

Every open source project live on GitHub is extremely different. The size and shape of project, GitHub Actions, and its purpose

Maintainers had very different ideas of what trust signals works for them


Heavy system interdependencies across interaction tools (eg: temporary limits, block)

Formation

Letting evidence write the principles

Opinion-based guidance gets ignored and evidence gives the guidance authority. So, I traced every principle back to a finding. I measured how instances of delegating overlapped with other patterns across 81 other scenarios. For example, prompt showed a 60% overlap, generate showed a 56% overlap, and create showed a 24% overlap. This provided direction to clarify points of friction, and redefine what pattern “delegate” multiple times..

Widen the definition

Agent-driven analysis narrowed down “delegate” applicable to agents only. However, human delegation such as, assigning an issue to a colleague through actionMenu or using Copilot to do so, is the same intent. I changed it to include both humans and agents and provide additional guidance which helped provide high-level guidance and cover all implementations.

Context is costly for agents; trading specificity for broader patterns to stay lean and fit new cases

Every fetch costs an agent context and there is a thin line between specificity and scenarios. Trimming down on specific examples like examples for “delegate entry points”, helped maintain high-level resonance and provide space for any new instance of delegate in future.

Recovery and exit from a delegation process

Two gaps: returning to a session later and any sort of graceful degradation from unexpected results. We call these error states and edge cases in UX. An external accessibility review pushed for a lot more work here. In particular, there is a grey area between accept and reject actions depending upon scenarios. After analysis and evaluation, the outcomes are now: accept, request changes, revert to a prior state, and try a different approach.

AI reviewers helped security measures

I saw the AI reviewer, running a degraded pass, flag that "Persist reasoning steps and tool calls" may encourage storing secrets, tokens, and internal prompts. Three humans had missed it. I decided to rewrite the guideline. Because a design system is the worst channel for a bad security default. It changed the page to a high-level activity log that avoids sensitive content.

Results

Scenario patterns now resolve ahead of generic UI patterns where agents look for guidance. A repeatable process now exists for the next couple of scenario pattern batches in the future. Analysis, drafting skill, guide, exemplar page, and a review chain.

Batch 2 merged live with five pages, llms.txt, and GitHub's Primer MCP

Decreased time for completion by 64% from batch 1 release to batch 2 release

Next

This is something already in the works, but now that guidance reaches agents, the next constraint is proving they follow it accurately. Matching is weak and a scorer is in the process. This could be a skill that scores generated UI against a pattern or anything really.

Takeaways

A design system that agents can read is only as good as how accurately it carries intent into action. The hardest pattern to write was the one about handing work over, and it came down to keeping people informed and able to step back. Guidance shapes what gets built next, so it should describe the standard we want, not only the one we have

Collaborators

Joe Lamyman (Tetralogical accessibility)

Siddharth (Primer engineer)

Copilot :) (AI review)