Most design system teams still pitch their work as a component library. Romina Kavcic, who runs The Design System Guide, argues that framing is why the work keeps getting cut. Her reframe: a design system is infrastructure, in the same category as your CI/CD pipeline and your database. To prove it, she took a control loop IBM first published in 2003 and rebuilt it for design systems. This is what she showed on stage at the AI Conference for Designers 2026.
TL;DR
- A design system is infrastructure, not a component library. Romina's framing for leadership: it is "an API that allows AI to build your product safely"
- The job moved from syntactic to semantic. AI generates code. Design systems generate understanding. Only one of those is now cheap
- None of it works unless the agent has something to read. Component descriptions, naming conventions and intent are the real asset
- MCP and CLI are different tools for different jobs. CLI for local single-tool tasks and fewer tokens, MCP when you need structured data from many tools at once
- The self-healing loop is MAPE-K: monitor, analyze, plan, execute, around a shared knowledge graph. IBM first published it in 2003
- Agent trust levels work like career progression. An intern can only suggest. Risk times confidence decides what ships. Some decisions never pass level 3
- Plant seeds, not trees. Structure before automation. "You don't have to think about an elephant. Maybe a mouse today is completely fine"
What is an agentic design system?
An agentic design system is a design system that AI agents can read, act on and contribute back to. Instead of a human applying tokens by hand, agents monitor the system for drift, analyze what broke, plan a fix and either open a pull request or apply it, depending on how much you trust them.
What makes it agentic rather than a chatbot is three things: autonomy, tool usage and feedback loops. A chatbot is ping pong. You prompt, it answers, you prompt again. An agent gets a goal and stops when the goal is reached.
Why is a design system infrastructure and not a component library?
Romina's opening line was blunt:
"I see design systems as an infrastructure. The same way as you can see your CI/CD pipeline or the database."
The argument has two halves. Product teams have always wanted to ship fast. What is new is that AI generates code at a scale no review process was designed to absorb. Put those together and:
"The only thing that stands between you, inconsistencies and your product is actually the system that governs it."
Which gives you the sentence to use in your next budget conversation:
"If you still need to justify design system to leadership, you can frame it as infrastructure, because this is what it is. It's like an API that allows AI to build your product safely."
Nobody asks the database team to prove their business value. Everyone already knows what happens without it.
What changed in the last nine months?
Romina presented at Into Design Systems the year before on context-aware design systems. Back then it was an idea. This year she came back to show it running. The numbers she used to explain the gap:
| Signal | Figure |
|---|---|
| Frontier models published in nine months | 28, more counting the Chinese models |
| Investment | more than $200 billion |
| MCP downloads | 100,000 to more than 8 million |
| Enterprises using agents by end of year (Gartner) | 40% |
| Code written last year that was AI-generated | around 40% |
Her point was not hype, it was the cost curve. Generating code is now close to free. Open Claude Code, ask for a dialog, and you have something in under 30 seconds.
AI generates code. Design systems generate understanding.
Ask developers whether they spend more or less time coding since adopting AI and the answer is less. The work moved from syntactic to semantic: from "how do I write this" to "what should this component do, and why".
"I think that that is exactly the shift that design systems need to make."
So the answer to "will AI replace design systems" inverts. AI makes them more critical, because the two do different jobs. AI generates code. Design systems generate understanding. One of those is now abundant.
The practical version:
"None of this works unless the agent has something to read."
An agent reads your context, thinks, plans, then acts. It pulls your component index, token structure and usage guidelines, works out that a destructive confirmation needs a dialog, a button with a destructive variant and an alert with a warning slot, then builds. Give it nothing to read and it guesses at machine speed across every surface.
Romina was honest about her own starting point. Most components had no descriptions. Documentation lived in Storybook, some specs lived in Figma and nothing was combined into anything useful.
Why should you plant seeds, not trees?
Romina stopped on one slide and said:
"I think this slide is the most important thing in this talk."
Two pictures. On the left someone planting seeds: you plant, you water, you wait, the growth is slow but real. On the right someone carrying a fully grown tree into their garden.
"It looks impressive on day one, and everyone wants to have a tree, and everyone wants to have a fully autonomous agent that just comes and fixes everything, but this is not how it works."
The seeds are the boring things: naming conventions, token structure, component descriptions. Then automation on top. Never the other way round.
MCP vs CLI: which one should you use for your design system?
This is the distinction most teams get wrong. Both are ways to let an agent touch your tools. They are not interchangeable.
| CLI | MCP | |
|---|---|---|
| What it is | Direct command execution | Model Context Protocol, a standard way for an agent to connect to external tools |
| Best for | One tool, one straightforward task | Multi-agent orchestration across several tools |
| Context cost | Less context, fewer tokens | More context, structured data from many sources |
| Where it runs | Local | Connects your tools to the agent |
| Example | Open Figma and Claude Code, say "these are my light theme colors, generate the dark theme list" | Pull design data, analytics, docs and code together so the agent can reason across all of them |
Romina's description of MCP is the clearest one I have heard: it is like a USB for all the tools your design system needs.
The MCPs she actually uses:
- Figma for design data
- Granola for meeting notes, so decisions made in a meeting can reach the system
- Mintlify for documentation
- Playwright for visiting the live site, running audits and taking screenshots
Different tools for different jobs, not one or the other.
What is a design system knowledge graph?
A knowledge graph is nothing more exotic than connecting everything your system already knows, so an agent can reason across it instead of guessing from one source.
The reason it cannot just be Figma: code is the last thing the user sees. So Figma holds the design decisions, PostHog shows what components actually do in the wild (it is an MCP and it can be self-hosted), and GitHub, Storybook, Linear, Chromatic and Playwright fill in the rest.
If that list makes your stomach drop, Romina's advice:
"Don't be afraid that the first thing is that you need to connect 10 MCPs, no. You just have to write one file in the beginning, and just write whatever you know, and how these things connect. And then you start adding more and more."
What is the self-healing design system loop?
The self-healing loop is MAPE-K: Monitor, Analyze, Plan, Execute, around a shared Knowledge base. IBM first published that loop in 2003 in its autonomic computing blueprint and refined it through 2006, though the MAPE-K acronym itself was coined later by the research community. It is the same reference model that telecom standards use for self-managing network automation.
Romina's point was that she did not need to invent anything. It is the same problem, so she applied it to design systems.
- Monitor. Signals are your sensors: the Figma API, CI hooks on every push, usage analytics from PostHog. Every change generates a signal
- Analyze. A drift scoring engine. Select an alert component, change a hex code or apply the wrong design token and it knows immediately, then opens a PR ticket
- Plan. The system decides what to do next
- Execute. Tied to trust levels. It fixes directly, or it only drafts a PR
So a token drifts, violations show up, the health score drops, the agent renames a few things and the score climbs back.
The knowledge graph sits in the middle: rules, token taxonomy, learning history, design principles. But writing the rules once is not enough. The graph has to sync with what is happening today, not yesterday.
What are agent trust levels in a design system?
Trust levels decide what an agent is allowed to do without a human. Romina models them on career progression: an intern can only suggest and every action needs approval, a junior can fix minimal mechanical things, and so on.
"Every time you hand over decision-making to an agentic design system, you're giving up a little bit of your control, and you want to make sure that the agent earns your trust."
But the level is not what decides. Risk and confidence decide:
| Risk | Confidence | What happens |
|---|---|---|
| Low | High | Auto-merge and ship |
| Low | Low | Draft a PR, request a review, involve the human |
And the sentence most AI content refuses to say out loud:
"Some decisions will never go past level 3, because things will always need some human judgment."
Her position on autonomy is more honest than most:
"I'm not really a fan of letting AI run wild. You still have to put some guardrails in."
The goal was never full autonomy. It is autonomy that still feels safe, with human oversight where it matters.
She was also clear about the cost nobody budgets for. In the beginning you babysit: you review every suggestion and correct every mistake, because that is how the agent learns your standards. Skip it and you get thousands of lines of generated code to review, and you will get lost in it.
How do you make agent work visible to your team?
A smaller thread, but a real problem. Once your prompts, skills and rules live as Markdown files inside Cursor or Claude Code, nobody else can see them.
"If I take this Markdown file and put it in my local environment, you will never see what happened with what I've created, or was it successful."
So Romina built a dashboard she calls the observatory. It shows which systems exist, which are connected to each other, which Markdown files are in play and who uses them, and it lets her read, edit and pause them in one place. Next to it sits an inbox: everything that needs her attention, each item linked to its PR ticket.
The Figma side is a plugin she calls Tidy, four letters because it is easy to remember. It audits naming, scores health across six categories and validates new variables against your naming conventions. She said it now exposes 66 MCP tools for tokens, components and health scoring. She was careful to note that much of this is still experimental, and that detail which turns out to be over the top gets removed based on feedback.
What can you do on Monday?
Romina closed with the most concrete starting point I have heard on this topic.
- Give the agent something to enforce. Start with one rule, not a platform
- Write down your naming conventions. This is the file the agent reads first
- Add 10 components. Or 5. That is enough to learn from
- Start with two simple MCPs. Figma and GitHub, or GitLab, or whatever holds your code
- Then play with it. A token validator is a good first project
"You don't have to think about an elephant. Maybe a mouse today is completely fine."
Her closing line, which is also the whole talk in six words: plant seeds, not trees. Structure before automation.
Key takeaways for design system teams
- Pitch the system as infrastructure, not as adoption metrics. "An API that allows AI to build your product safely" is the line that lands with people who control budget
- Steal MAPE-K. The loop is 23 years old and battle-tested in infrastructure automation. Nobody needs a new framework here
- Write trust levels down before you build automation. Risk times confidence, decided in advance, is a much calmer conversation than deciding per incident
- Budget the babysitting phase. It is the training, not the overhead
- Use CLI for the cheap local jobs, MCP for orchestration. Choosing wrong costs you tokens or capability
- If your Markdown files are invisible to your team, they are invisible to your team. Visibility is a feature
Frequently asked questions
What is an agentic design system?
An agentic design system is a design system that AI agents can read, act on and contribute back to. Agents monitor it for drift, analyze what broke, plan a fix and either open a pull request or apply it directly, depending on the trust level you granted them.
Why is a design system infrastructure and not a component library?
Because AI now generates code at a scale no review process was built for, and the system that governs consistency is the only thing standing between that speed and a broken product. That puts it in the same category as a CI/CD pipeline or a database, not in the category of a UI kit.
What is MAPE-K?
MAPE-K is a control loop: Monitor, Analyze, Plan, Execute, around a shared Knowledge base. IBM first published it in its autonomic computing blueprint in 2003 and refined it through 2006. The acronym itself was coined later by the research community. Applied to a design system, it becomes a self-healing loop.
What is the difference between MCP and CLI for design systems?
CLI is direct command execution: local, straightforward, fewer tokens, best for one tool and one task. MCP is the Model Context Protocol, a standard way for an agent to reach many tools at once. Use MCP when you need structured data from several sources for multi-agent orchestration.
What are agent trust levels?
Trust levels define what an agent may do without human approval, modelled on career progression from intern upwards. The decision is risk times confidence: low risk and high confidence can auto-merge, low confidence drafts a PR and requests a review. Some decisions never pass level 3.
How do I start building an agentic design system?
Start with one rule to enforce. Write down your naming conventions, add 5 to 10 components with real descriptions and intent, connect two MCPs (Figma plus whatever holds your code), then iterate. Structure first, automation second.
Why do AI agents get design system decisions wrong?
Because they have nothing to read. If components have no descriptions, if intent lives in someone's head and if naming is only mostly consistent, the agent guesses. The fix is metadata and written intent, not a better model.
Related reading on agentic design systems
- How Miro Made Their Design System AI-Ready with MCP and Claude Code Skills
- How Spotify Is Making Their Design System AI-Ready
- Is Your Design System Ready for AI Agents?
- What Design Teams at WhatsApp, Miro and Adobe Learned Shipping with AI
- Agentic Design Systems
Watch the full session on demand
Romina's session "Agentic Design Systems" is one of 18 from the AI Conference for Designers 2026. The recording includes the full talk, the live demos of the Tidy plugin, the observatory and the pattern composer, plus the Q&A on the FigJam board.
About Into Design Systems
Into Design Systems teaches designers how to build with AI agents. We run the AI Conference for Designers, hands-on workshops and a community of design system practitioners who ship. If you want the workflows behind agentic design systems, start here.