Picture a design system that's mature. There is a single source of truth. Each foundational definition is intentionally designed, documented, tokenized, and implemented, ready for consistent consumption across platforms. Governance and contribution models are readily available.
And still, parts of the company won't touch it.
Some teams pretend it doesn't exist. Others fork it and never come back. Engineers say they can code it faster themselves. The contribution channel goes quiet for weeks.
If you've built or led a design system at any real scale, you know this story.
The adoption problem is the part nobody likes to talk about, because it doesn't have a clean fix. There's no tool you can buy. No framework that makes it disappear. And right now, with AI agents entering every product workflow, the adoption problem is getting louder, not quieter.
Here's what we've been seeing across the design and engineering teams we work with, and what's actually moving the needle. If you'd rather hear us talk through some of this, our podcasts dug into adjacent ground on Intent & Craft and Even-Keeeled.
The adoption problem isn't new
Design system adoption has never been easy. The mechanics that block adoption today were blocking it years before anyone wrote an MCP server.
Here are a few patterns we see, especially inside enterprise orgs supporting large teams of designers and engineers:
1. The "I can build it faster myself" mindset
Engineers under sprint pressure don’t want to take extra time to build a design system compliant component when they are focused on a very product-specific use case. That's a real time cost they're absorbing. The design system asks them to trade short-term speed for long-term consistency, and short-term wins almost every time.
2. The cold-start problem
Not every engineer lives in front-end work. Full-stack and platform engineers rotate in for a sprint or two, ship the feature, and rotate back out. By the time they're in the design system again, what they knew about it has faded. Every return is a ramp-up. The system never quite becomes muscle memory.
3. The infinite availability paradox
When the design system team is always available to help, teams happily wait. "I can't ship this until the design system supports it" becomes a reason to push something off to the next sprint. The team's openness becomes the bottleneck.
4. The acquired-company patchwork
For orgs that grew through acquisition, dev cultures fragment fast. Each acquired team brings its own conventions, its own tools, and its own rituals. The design system has to serve them all, often without anyone agreeing it should.
5. The contribution gap
"Yeah, we'll wait three weeks for the design system team to add that, and patch it ourselves in the meantime." That patch becomes a one-off. It never gets contributed back. The next team writes their own version of the same thing six months later.
None of this requires AI to be a problem. AI just changes the volume.
AI amplifies what was already broken
We've spent a lot of time over the last year talking with design and engineering leaders about agent-ready design systems and we’ve seen that most teams don’t have a new problem.
They have an older problem with more pressure on it.
AI amplifies three existing fault lines.
1. Speed amplifies drift
When a human occasionally strays from the system, the cost is manageable. When an agent strays, the cost compounds fast across every screen, every product, every team using that agent.
2. Skill files inherit the contribution problem
Teams copy a skill file, modify it for their context, and never push the changes back. Now there are two divergent versions of what was supposed to be a shared workflow. The same dynamic that already breaks contribution at the component level just got moved up a layer.
3. AI surfaces the replacement anxiety
Engineers hear "the design system makes you faster, and AI makes you faster" and read it as "you're replaceable." That fear shows up as resistance to both.
There's a useful way to frame what's happening here
Design system adoption actually fails on two axes at once.
- Mechanical adoption is whether people are technically using the system.
- Trust-based adoption is whether people believe it's worth using.
AI puts pressure on both at the same time.
That's the bad news. The good news is that the same moment forces a useful question: what does the design system team actually have to own, and what can be distributed?
In an “agent-driven world,” one decision really can make a thousand. That's a multiplier your design system never had before.
What's actually worked
There's no silver bullet. We have to say that up front, because we've been in enough adoption conversations to know that anyone selling one is selling something else.
But there are mechanisms we've seen move the needle. They share one trait: they make the path of least resistance run through the design system instead of around it.
Make contribution boring and obvious
The fear of contribution is bigger than the work of contribution. Most engineers we've walked through a first contribution come out the other side saying "oh, that wasn't so bad." The job is to lower the activation energy, not the actual difficulty.
In practice, that looks like:
- Documenting the contribution steps explicitly. Not "open a PR," but the full path from "I noticed a gap" to "my change is in main."
- Naming what would make a great contribution. "This filter pattern would be valuable in the system. Want to take the first pass?" beats an open invitation every time.
- Walking the first contribution end to end with the person. Once they've shipped one, they'll ship more on their own.
Let contributors test safely before going public
One technical move that's worked well for our development teams: snapshot publishing to a private registry. The contributor publishes their version of the component, tests it inside their own app, and never has to make it publicly available until it's reviewed and ready.
That removes the fear that an experiment will get loose. They get to validate the change in a real context. They never feel like they're proposing something to thousands of users before they're sure it works.
Move design system engineers into the dev org
Counterintuitive, but we've watched this work at multiple client orgs. When the design system engineers report into engineering instead of design, two things shift. The work has more credibility with the rest of the dev org. And the friction of "designers telling devs what to do" disappears, even if nobody was saying that out loud.
The design partnership stays close. Day-to-day collaboration doesn't change. The reporting line does.
Centralize what's non-negotiable. Distribute what's contextual.
This is the agent layer where we've put the most thought.
The pattern we keep coming back to: a custom MCP for the non-negotiable rules of the design system, plus skill files for the deviations that depend on platform or context.
The MCP
The MCP is the centralized source of truth. Install once. It tells the agent what components exist, what their props are, what tokens to use, and what to do when faced with ambiguity. It's harder for individual developers to tinker with under the hood, which is exactly the point. Centralization is the feature, not a bug.
MCP’s also make distribution simpler. Leveraging your existing package manager to install your design system MCP takes advantage of your existing workflows. It also supports versioning in a way that other solutions don’t. For example, your MCP can release on the same schedule as your design system itself and your engineers can match the version of the MCP with the version of the design system UI Kit their product is using.
Skill files
Skill files handle the cases where context legitimately changes the answer. A team shipping in Flutter and a team shipping in React both need to know about your button component, but the implementation differs. Skill files tailor for that without forking the core rules.
The reason we lean centralized for the core
Skill files have the same contribution problem as components. If everyone forks their own, the system is fragmented again. The MCP doesn't get forked. It gets updated.
Worth noting on cost
A locally running MCP is cheaper than a hosted one. The free token world is wrapping up. Anything you can do to avoid hosting auth and burning credits adds up across an org with thousands of engineers.
Run adoption reports. Then have a conversation.
You can't fix adoption you can't see. We've built internal tools that scan codebases and tell us which teams are using the design system, which teams are using it minimally, and which teams haven't engaged at all.
The point isn't to catch anyone. It's to start a conversation with the leads of the teams that aren't engaging. What's blocking them? Is it documentation? A missing component? The fact that nobody on their team has ever talked to the design system team and they don't know where to start?
One realistic caveat: telemetry inside shipped software gets complicated fast in regulated industries. If your data privacy posture won't let you put hooks in production, do this through repo-level scanning instead. Either way, the data is just the starting point. The work is the conversation.
Reframe AI as the assistant, not the threat
The replacement anxiety is real, and ignoring it makes adoption worse. We've been deliberate about how we talk about AI in our own work and in our conversations with clients.
The simplest reframe: AI is an assistant for the same goal you had before AI. Ship a quality product. Serve your customers. The agent doesn't change the goal. It changes the speed of getting there when the design system supports it well.
That reframe matters because engineers who hear "AI will make you faster" alongside "the design system will make you faster" hear two things racing each other to replace them. The real story is that both exist to support what they're already trying to do.
The other half of the reframe is honest about what AI can't do. AI outputs what already exists. It doesn't innovate. It doesn't have taste. It doesn't understand your specific user the way a designer who's watched them work with the product does. For specialized domains, especially, human judgment isn't a nice-to-have. It's the part that makes the product worth shipping.
When teams hear that framing, the resistance to the tooling drops. Not because the tooling changed. Because the perceived threat went away.
Adoption is a culture problem. Always.
We'll close where every honest adoption conversation lands. The design system can be perfect. The agentic tooling can be flawless. There will still be parts of the company that don't engage. That's because design system adoption is a culture problem, and every culture is different.
The mechanisms in this piece help. Documentation, snapshot publishing, the MCP-plus-skill-files architecture, adoption reports, and language that defuses replacement fear. All of it helps. None of it removes the conversational work of meeting teams where they are and figuring out what specifically is blocking them.
The teams we've watched solve this haven't found the right tool. They committed to the conversations. The tools made the conversations easier.
If you're a design system lead reading this and feeling like the adoption problem is bigger than the tooling you've been handed, you're right. It is. That doesn't mean the tooling doesn't matter. It means the tooling is one move in a much bigger play.
If you're working through the adoption problem at your org and want to think through it with people who've been in the weeds on it, we'd love to chat. Schedule a free consultation, explore how we work with design and development teams together, or take a look at our design systems work more broadly.
If you want a short, focused engagement to assess where your system stands, ask us about our Agentic Design System Roadmap.
