Your design system needs an operator, not more documentation

A design system that nobody operates will drift away from the product it is meant to describe. In 2026, most design systems are three things that disagree with each other: a documentation site, a Figma library and a component package. Teams usually know which of the three is wrong this week. Nobody has the time to fix it.

This problem used to grow slowly. It now grows quickly, for two reasons. Design-system teams are getting smaller, and the readers of a design system are no longer only people.

By "operator" I mean a person or a service whose job is to run the system every day: to check it, correct it and keep it consistent. Documentation describes a system. An operator keeps it true.

A design system is no longer a library you publish. It is a service you run.

Small teams now carry large systems

The zeroheight Design Systems Report 2026 (survey of 147 practitioners, published March 2026) puts numbers on a situation that many teams already recognise. According to figures shared in zeroheight's launch webinar, 16% of systems are run by one person. Only 23% say they are adequately resourced, and 56% name staffing as their biggest challenge. The title of the webinar stated the problem directly: "We need more people."

Those people are not coming. Headcount plans for 2027 do not include a bigger design-system team. They include more AI-assisted delivery.

The question for a design-system lead is therefore not how to get three more hires. The question is how one person can keep a system correct while the number of things that consume it doubles.

Agents are now the heaviest users of your system

The most frequent reader of your design system is no longer a designer browsing the documentation site. It is a coding agent in Cursor, Copilot, Claude or Codex that has been asked to build a settings page before lunch.

The tooling market has already accepted this. Supernova, zeroheight, Knapsack, Figma and Storybook/Chromatic all shipped MCP servers in 2025 and 2026 (see Figma's design context announcement, Storybook's MCP docs and Knapsack's MCP server). In its own Config 2026 messaging, Figma said that agents without design-system context feel "unfamiliar and generic."

Giving agents access to a design system is now the minimum that teams expect. The harder problem is what happens when the system you expose is partly wrong. A person reading an outdated documentation page may notice that it looks old and ask a colleague. An agent does not. It follows the page. If your Button documentation still mentions a variant="danger" that was renamed a year ago, the agent will use it, with confidence, in forty files.

A team of people drifts away from the system slowly. A team assisted by agents drifts as fast as the agents can write code.

Documentation is not governance

Documentation describes what the system should be. Governance decides what the system is allowed to become.

ZURB's review of Config 2026 made this point clearly. Figma's new Check designs feature can "put a number on your design-system debt," but it "didn't hand you the budget." Counting drift is useful. It is not the same as sending each finding to an owner, deciding whether it is a bug or a legitimate exception, and shipping the fix.

A governed system has answers to concrete questions:

• Who owns DatePicker, and who approves a breaking change to it?
• What happens to the 12 local copies of Card that teams built because the official one lacked a footer slot?
• When a token is deprecated, which consumers still use it, and who migrates them?
• Is a new request a reuse of something that exists, or genuinely new work?

If those answers exist only in one person's memory, the whole system depends on that person. In 16% of organisations, the system is run by exactly one person.

A system that allows off-brand work is not a system

Most systems stop at tokens and components. Those are the easiest parts to enforce, so enforcement stops there.

The parts that make a product feel like your product are rarely the radius of a button. They are the illustration style, the tone of an error message, the word you use for "workspace" and the way a date reads in German. These rules usually live in a brand PDF, a Notion page or the glossary of a localisation vendor. None of them can be checked automatically.

This was acceptable when a writer and an illustrator reviewed every screen. It is not acceptable when an agent writes the empty state. An agent will produce "Oops! Something went wrong 😅" in a product whose voice guide forbids both "oops" and emoji, because nothing in its context tells it otherwise.

If a rule cannot be enforced, it is only a suggestion.

If brand, illustration, microcopy and localisation rules cannot be enforced, they are suggestions. A system made of suggestions will produce off-brand work the first time a team is short of time. These rules need to be written so that an agent can read them before it writes and a reviewer can check them afterwards: preferred terms, banned phrases, string length budgets per locale, and which illustration set belongs on which surface.

Your repository and Figma stay the sources of truth

For a decade, design-system teams have argued about whether Figma or code is the source of truth. The argument misses the point. Both show what actually exists, so both are sources of truth. What is missing is something that governs them and notices when they drift apart.

The repository is where agents work. It is versioned, it can be reviewed and it is already connected to continuous integration. Tokens in DTCG format, whose first stable version shipped in October 2025, can live there next to component contracts and content rules. Figma is where designers work, and its variables and libraries are just as real. Loom governs both and flags anything that drifts, so that a difference becomes a decision rather than a surprise.

This has a practical consequence for any platform that operates a design system. The platform should write to the customer's repository through pull requests. It should not keep the system inside its own cloud, where the customer cannot leave without losing it. Every change should be reviewable. Every change should be revertible. There should be no lock-in.

Audit, convert, operate

Our view is that most teams do not need another place to document their system. They need someone to fix it, and then to keep it fixed. That is three distinct jobs.

Audit. Make an inventory of what actually exists, in code and in design. Score structure, usage, guidance and governance separately. Find the components in production that have no rules, the places where code bypasses tokens, and the local re-implementations of system components.

Convert. Turn what you have into a governed system without changing how it looks. This means typed DTCG tokens with semantic layers and modes. It means a contract for each component that covers purpose, anatomy, API, states, behaviour, accessibility and content rules. It means a governance model with owners, a contribution flow, semver, deprecation and a changelog.

Operate. Watch usage and drift. Draft fixes and migrations as pull requests. Let people review, decide and release. The AI does the upkeep. People keep the authority.

This is what we built Loom to do. At launch, Loom runs the audit and conversion, serves the result to agents through an MCP server that can look up the system, build on-system UI, audit code and propose changes, pushes tokens to Figma as variables with a generated component library and drift detection, and generates Storybook. Continuous monitoring and content enforcement for illustration, microcopy and localisation are on the roadmap and shown as concepts in our demo, not as shipped features.

What "AI-ready" means in practice

The term "AI-ready" is at risk of meaning nothing. This is the checklist we use. A system is AI-ready when:

1. Tokens are typed and semantic. DTCG format, with a semantic layer (color.text.danger) over primitives (red.600) and explicit modes for theme and density.
2. Every component has a machine-readable contract. Exact import path, props with types and defaults, states, slots, and when not to use it.
3. Accessibility obligations are explicit. Required labels, focus behaviour, keyboard map and contrast pairs, per component.
4. Content rules are data. Voice, preferred and banned terms, string length limits and locale constraints are in the repository, not in a PDF.
5. Usage is measured. You can list components in use that have no contract, and the rate at which code bypasses tokens.
6. Governance is a process with owners. Each component and token group has a named owner, a contribution path and a deprecation policy.
7. Changes are versioned. Semver, a changelog an agent can read, and migration notes for breaking changes.
8. The repository is canonical. Figma, Storybook and documentation are generated from it or checked against it.
9. Agents can check their own work. An audit step exists that an agent can call before it opens a pull request.
10. People approve. No automated change reaches production without a reviewer.

If your system meets fewer than half of these, your agents are guessing. They will guess in front of your users, at scale, in the name of your brand.

Give the system an operator

Design-system leads should stop measuring their system by how complete its documentation is. They should measure it by whether the system stays correct when agents use it every day. Leaders who fund these teams should recognise that a small team cannot keep a system correct by hand while agents consume it at this speed.

A design system is no longer a library you publish. It is a service you run, and it needs an operator.

Continue the conversation

These sources, cited above, give more detail on the state of design systems and the tools around them.

Design Systems Report 2026 by zeroheight

A survey of 147 practitioners, published March 2026, on how design-system teams are staffed and resourced.

Review of Config 2026 by ZURB

A review of Figma's Check designs feature and the difference between counting drift and fixing it.

First stable version of the Design Tokens specification by the W3C Design Tokens Community Group

The announcement of the first stable version of the DTCG format, in October 2025.

Design context announcement by Figma

Figma's announcement about design context for agents, one of the MCP releases described above.