A lesson from my work on the JM Family design system: making standards available to coding agents changes how teams build, and what maintaining the system requires.
Recent accessibility work on Ask Hubert, an internal AI assistant my team builds at JM Family, brought keyboard navigation across the application in line with our standards. It got there the way this work often does: find what is off, write it up, fix it. Coding agents made each of those steps faster, and the engineers doing it knew what correct keyboard behavior looks like without needing anyone to tell them.
Color went differently. Once the Agent Kit was integrated, the application used the right tokens. The kit packages the design system's tokens, registries, and instructions so they travel with the code. Tokens give shared names to design values, including colors, so an agent can use the agreed value instead of choosing its own. No audit, no backlog item, no conversation about which blue. The standards were available at the moment the code was written, so the code came out matching them.
Same product, two paths to the same kind of correctness. The difference is whether the standard was there before the work started.
That difference is where governance is moving. Many of the quality conversations I have been part of happened at review, after the code was written and a date was committed. Review made sense, because it was the first moment anyone could judge the work. The cost was that governance arrived as a negotiation. A standard raised at review is one more thing competing with a date that is already committed, and the date usually wins.
Review depends on production moving slowly enough for someone to keep up. When code arrives faster than anyone can read it, review alone cannot carry that responsibility. The standards need to be part of what the agent builds from.
Standards make governance part of production. That is what makes a design system enterprise infrastructure.
The design system I built at JM Family explains its decisions: why a pattern behaves the way it does, what it protects, and when it does not apply. People read that on the documentation site. Agents read the same reasoning through the Agent Kit. One set of decisions, two audiences.
That reasoning travels further than the code. It can show up months later, in another business unit, in a decision made by someone who read a page and agreed with it. The original author may never be in the room.
There is no version number on a decision someone has already accepted. Counting how many teams have adopted the system tells only part of the story. Someone also has to answer when one of its standards turns out to be wrong. Every team that uses the system trusts that the reasoning behind that standard was sound when it was written, and that someone is still checking whether it holds. That trust is invisible until the day it is missing.
This is the part I find hardest in my own work. Writing a new standard is the satisfying half. Going back through what is already published, in a week where nothing is on fire and nobody has asked, to confirm that a decision made eight months ago still holds, is the half that keeps the rest of it true.
That responsibility reaches across the enterprise, even when the maintenance looks like a small job. Teams in different business units depend on the same foundation. Because the system is built on tokens, a subsidiary brand can eventually apply its own theme without maintaining a separate copy of the system. That payoff only arrives if the foundation is still sound when the brand needs it.
A system the software gets built from needs an owner, a version, and a way to be told it is wrong. We would not accept less from any other shared service.
The design-system case study shows how I have put that into practice, with the reasoning next to the standards and an Agent Kit generated from the same source. Publishing the reasoning gives teams something they can inspect and challenge. A standard that has been argued with is stronger than one that has only been published.
The tools will keep getting better at matching whatever we hand them. What they cannot do is decide whether what we handed them is still right. That judgment does not get made once. It gets made again every time a product, a platform, or a policy changes and a decision we made a year ago has to be checked against it. That is the work the next several years of our products will rest on.