Built to Hold

A front-end engineer joined a design systems team. Smart, fast, three years in. In her first week she shipped a component with a hardcoded hex instead of the token. The team caught it in review, walked her through the documentation, pointed her at the right path. In her third week she did it again, in a different component.

When they asked why, she said the right token existed and she knew it existed. Looking it up was slower than shipping.

That sentence is the whole problem. The system knew the answer. The person could not get to it fast enough to use it under real conditions.

Now imagine an agent writing the same component. It queries the design system directly, gets the right token name back in 200 milliseconds, and the hardcoded hex never enters the codebase. The system did not get smarter. It got queryable. That distinction is most of the next decade of design systems work, which will be a slow migration from systems people are supposed to consult to systems that things actually query.

For ten years the design systems community has been building coherence for humans. Naming conventions, token architecture, governance models, documentation standards. Something a designer can look up, a developer can reference, a DesignOps lead can audit. The discipline has matured and the work has been good.

It has also hit a ceiling most teams have met without naming. The governance model most studios run depends on a person maintaining the system, a process enforcing the standard, and a meeting surfacing the drift. It is reactive, expensive, and it holds right up until the organization starts moving faster than the people maintaining it. By the time the quarterly audit catches a divergence, the divergence is already in production. And the layer that fixes this is being designed right now, in platform engineering meetings and developer tooling roadmaps, by people who understand the protocol but have never had to defend a token name or sit through the governance meeting. That is the part worth paying attention to.

What comes next is making the design system legible to machines.

I have been calling this MCP-driven design systems, after the Model Context Protocol that exposes structured resources to agents and tools. When a token file, a component spec, and a usage pattern dataset live on an MCP server, they become queryable rather than referenceable. An agent in any tool that speaks the protocol can ask what the correct color token is for a primary call-to-action in an error state, and get a structured answer from the source of truth in real time.

I wrote a while ago about antifragile design systems: the idea that a system can improve from the production stress that would otherwise wear it down, the way an immune system gets stronger from the exposure that could have made it sick. That essay was about a feedback channel that catches an inline override after it ships and routes it back into the system on a monthly cadence. Healing, after the fact. The queryable layer is the other half of the same body. Not the immune system but the nervous system: the part that senses and answers in the moment, before the override is ever written.

Before this move, the design system answers when someone opens it. The cost of correct use is paid by the person doing the work. Look it up, find the right token, copy the right value, check that it still applies in the context you are in. After this move, the system answers when something asks it. The cost shifts off the person and onto the system. The human gets the benefit without paying the friction.

Three things change concretely.

Drift detection stops being periodic. Instead of a quarterly audit where someone checks by hand whether production matches spec, the system gets queried continuously by the agents working alongside the team. A component that diverges from its token spec produces a signal in days, not quarters. This is the antifragile feedback channel running at a new speed: the monthly triage I described before still sorts every signal into the same four buckets, token evolution, component extension, documentation update, or local decision, but now the signal arrives in the same working week it was created, while the context that produced it is still warm.

Governance becomes structural rather than behavioral. Most governance depends on people remembering to consult the system. The queryable version makes the consultation automatic. The agent checks the spec before it generates output. Correct use becomes the path of least resistance, which is the only condition under which correctness scales. A standard that depends on memory is a standard that produces drift.

The documentation problem changes shape. Most design system documentation is written for humans who read it before they work, which assumes they read it at all. The queryable version serves documentation to agents at the moment of work. The question stops being whether the team read the docs and starts being whether the system answered when asked. The agent-readable design system is a different artifact from the human-readable one, and the practitioners who own the second are the ones who should own the translation into the first.

Underneath the three is a single shift. Tokens become the validation boundary. Every generated interface, every agent-produced component, every machine-written piece of styling has to clear the same constraint layer a human contributor would. The design system becomes the place where intent gets enforced, not just the place where intent gets written down. The artifact you have spent ten years building stops being a reference and starts being infrastructure your product runs on.

The obvious objection is that this is just better autocomplete: a faster way to fetch a value a careful developer could have looked up. If that were all it was, it would still be worth doing, because the engineer in the story did not fail for lack of intelligence. She failed because correctness cost more than her deadline allowed, and the queryable system drops that cost to nearly zero. But a system that can be asked can also be checked against, by every agent in the codebase, continuously. The harder objection is the second one: a system that answers on the developer's behalf risks a developer who never learns the system at all. That risk is real, and it is exactly why the line further down is the most important thing in this essay.

The protocol is learnable in a sprint. The judgment that makes the system worth exposing is not. The token semantics, the governance model, the component spec, the question of what the system is actually for, all of it lives with the practitioners who built it. Teams that take the first move on their own terms get to design what the upper layers look like. Teams that wait inherit a version designed by people who never had to answer what design intent means or what good governance feels like from the inside.

The deeper commitment is the line under all of this. Intelligent systems should extend what a team can do. They should never replace how a team thinks. A design system that answers a developer who never opens the documentation is doing the first job. A design system that quietly substitutes its judgment for the team's is doing the second. The queryable layer has to keep that line visible. The point is not to take the design system off the team's hands. It is to put the system into the work, so the team spends its attention on the parts that actually need a person.

The Figma MCP server is shipping today. Install it this week, point it at your own token file, and ask it for the color token for a primary call-to-action in the error state. See what comes back. That first query is small, concrete, and available now, and the answer it returns is the start of a longer conversation about what the rest of the architecture should look like. The people who belong in that conversation are the ones who built the foundation it sits on.

Go back to the engineer in her third week. The token existed. She knew it existed. In a queryable system the value reaches her in the time it takes to ask, in the file she already has open, and the hardcoded hex is never written. She does not read more documentation. She does not lose the minutes. Her attention stays on the part of the component that needed her judgment in the first place. The system answered so she did not have to stop.

That is the whole of it. A design system you spent ten years teaching to know, finally able to answer. Healing was the first half: a system that metabolizes production stress on a cadence, so it grows more accurate to the product over time. Answering is the second: a system that responds in the moment, before the wrong value is ever written. A system that does both is one built to hold its shape as the product it describes keeps changing. It will learn to answer whether or not the people who built it are in the room when it does. The work now is making sure they are.