Think about the last time you brought a new designer onto a project that’s been running for a while. You give them access to the Figma files, walk them through the component library, and point them toward the documentation. There’s enough there to get started, but as they work, they begin finding things that need an explanation. A button looks different on one client’s site. Two components seem to do the same job. A color appears in a recent campaign but isn’t listed in the approved palette.
Typically, they ask someone. A teammate explains that the button was changed for a particular requirement, one component is being phased out, and the campaign color was an exception approved by legal. Those conversations help the new designer understand how to use the system and where to be careful. They also reveal how much of the system depends on knowledge that never made it into the documentation.
An AI agent encounters the same gaps. Depending on its instructions, it may ask for clarification, copy the closest example, or make a choice that seems reasonable from the information available. The result can look polished while carrying forward a decision that was never meant to be applied more broadly. As the agent produces more work, those small misunderstandings can create more drift that the team will need to correct later.
At DH, preparing a design system for AI starts with making that missing context available. That means defining which decisions the agent can make, documenting the rules and exceptions it should work from, and checking the results against the system.
Decide What The Agent Should Do
Before an agent touches the system, decide which tasks it should handle and which decisions stay with a designer. Generating variants from an approved component is a different assignment from deciding whether the system needs a new component. An agent needs enough guidance to recognize that boundary and know when to ask for clarification. Write down the rules it will encounter repeatedly, such as how tokens get named and when a new request belongs within an existing pattern. That gives the agent a basis for its choices and the reviewer a basis for evaluating them. Address errors directly rather than quietly tolerating them: define how the agent should flag uncertainty, report violations, and correct mistakes, and make clear that reviewers should resolve recurring problems instead of allowing them to become accepted practice.
Make Tokens The Contract
A card with 15px of padding can look perfectly reasonable beside one with 16px, which makes the difference easy to miss in review. Across dozens of components, those small departures can gradually weaken the consistency the system was built to provide. This is token drift: an implementation uses a value that is visually similar to an approved design token but is not the token itself. Drift can occur when an agent invents a value, copies a value from an unrelated component, converts between units inconsistently, or bypasses an existing token because the result appears close enough. The problem is not limited to spacing; it can affect colors, typography, radii, shadows, sizing, and other governed properties. We keep approved tokens in a structured file the agent can access and require them for properties the token system governs. When a spacing token already exists, the agent should use it rather than choose a value that looks close. That also creates a specific condition we can check instead of relying on someone to notice the difference: every governed value should resolve to an approved token, and any raw value should be treated as an exception that requires an explicit reason.
Put Documentation Where Agents Can Use It
Having documentation available doesn’t necessarily make it clear which guidance to follow. A component’s usage rules might live in a slide deck while a later decision sits in a project note, leaving someone to reconcile the two. We use markdown for working documentation and keep it next to the code so changes can be versioned together. Each component’s guidance explains when to use it, which tokens apply, and what requirements need checking. It should also cover conditions such as error states and tell the agent how to proceed when the documentation doesn’t answer a question.
Write Down The Exceptions
The campaign color from the opening is a useful example: its presence in a file tells you that someone used it, but it doesn’t explain whether you should use it again. This documentation manifests as a decision log that records why the exception was approved, where it applies, and what limits still hold. When that reasoning is available, an agent or a new teammate can distinguish a local decision from a change to the wider system. This becomes especially useful as people move between projects and the original conversation becomes harder to recover.
Package Repeatable Work As Skills
Some tasks require the same explanation often enough that it makes sense to document the guidance for future use. Naming a new token, generating an accessible palette, or auditing components for drift each involves recurring rules and decisions. Skills bring those instructions and relevant examples together so an agent can load them when the task calls for it. That reduces how much someone has to reconstruct in each prompt and gives the team a process they can inspect and improve. The output still needs validation, but the starting point becomes more consistent.
Automate The Checks You Can Define
As agents produce more variations, visual review alone becomes harder to manage. Automated checks can flag defined mechanical errors, including unapproved values, failed contrast requirements, and components detached from the library. Skills can guide how those checks run and how their findings are handled, provided the checks have clear criteria and a reliable way to evaluate the work. Passing them doesn’t settle whether a design is effective for the person using it. It does give reviewers fewer mechanical problems to sort through before they can focus on that question.
Make the rules available, then check the work
The questions a new teammate asks are a useful place to start. They reveal which decisions are documented, which depend on someone’s memory, and where the system leaves room for interpretation. The corrections that keep appearing in review offer another signal. Together, they can help a team decide what to document first and which checks would remove recurring work.
Preparing a design system for AI builds on that understanding. Define what the agent should own, make the relevant guidance available, and check its output against the rules you’ve established. As those gaps close, the team can spend less time explaining the same decisions and correcting the same mistakes, with more attention left for the work that drives the company forward.