Agents are now consumers of your design system. What changes for contracts, governance and the team, in what order to change it and what should stay human.
Design systems were built for a consumer who reads documentation, asks in Slack when unsure and ships a few components a day. That consumer now has a colleague who reads everything at once, never asks and ships in minutes. Most systems I see were never designed for this reader, and it shows: the agent does not misbehave randomly, it faithfully amplifies every ambiguity the system already had.
Leading a system through this shift is not primarily a tooling project. It is a re-founding of what the system is: from a component library humans browse to a contract layer that humans and machines both consume. When I led design system architecture for SAP Build Apps, we treated the system as an internal API for automation before generative tools made that fashionable. The reason was mundane, low-code tooling had to query what was possible rather than guess, but the stance turns out to be exactly what agent consumers need.
The most common failure I see is starting at the end: a team wires an agent to the component library, demos a generated screen and calls it transformation. Generation without contracts produces plausible UI that violates the system in ways nobody reviews closely enough to catch. The sequence that works runs the other way.
The order matters because each stage makes the next one reviewable. Contracts make agent output checkable. Guardrails make the checking automatic. Generation without the first two is drift with good marketing.
Governance used to answer one question: how do humans propose, review and release changes to the system. It now answers a second: what are agents allowed to do without a human in the loop. The artifacts are the same ones that always worked, RFCs, decision records, release checklists, but they carry new weight, because a decision record is now also agent context. Write down why a rule exists and both your next hire and your coding agent apply it correctly. Leave it tribal and the agent invents a reason.
One practical change I now push everywhere: every rule the system adds must name its enforcement point. A rule enforced by lint is real. A rule enforced by CI is real. A rule enforced by hoping reviewers notice is not a rule, it is a suggestion, and agents do not take suggestions.
Three things do not delegate. Taste: whether a composition is good, not merely legal, remains a human judgment, and pretending otherwise produces legal, joyless interfaces. Tradeoffs: when accessibility, brand and speed conflict, someone accountable chooses, and an agent optimizing one dimension will happily wreck the others. Accountability: when generated UI ships broken, the postmortem cannot end at the model. It ends at the contract gap or the missing guardrail, which is to say, at the team.
Not with a platform decision. Pick your five most used components and write contracts for them. Move two rules into the pipeline. Then run the cheapest honest experiment available: let an agent build one real screen from the contracts alone and review the result with the team. Every mistake it makes is a gap in your system that human politeness had been routing around. That review meeting, more than any strategy deck, is where the transformation actually starts.
Vague component documentation produces broken UI at machine speed. Machine-readable contracts are the fix, not better prose.
Enterprise-scale systems already treat the design system as an internal API. That stance transfers directly to agent consumers.
Governance artifacts, RFCs, decision records and release discipline, are the backbone of the transformation, not bureaucracy around it.
Enforcement has to move into the pipeline. Token rules at lint level and drift checks in CI are how coherence survives agent contributions.
The share link includes source tracking so LinkedIn traffic stays measurable in analytics.
Want help implementing this? Let's talk about your system or workflow.