Your design system should grow like a crystal, not set like concrete
In 1950, Bell Labs had a working transistor and no dependable way to make more of them. The obstacle was purity. A transistor works by adding tiny, precisely controlled amounts of impurity to a semiconductor, and that only works if you start from a material with almost no impurity in it to begin with. Growing germanium as a single crystal had already been figured out. Getting the contamination out of it had not, and William Shockley was leaning on the people whose job it was to solve that.
One of them was a chemical engineer named William Pfann. By his own account, the answer arrived during a nap. He was tipped back in his chair with his head against the office window sill, and he sat up fast enough that he remembered the chair legs cracking against the floor.
What he had seen was that you do not have to purify the whole bar at once. You can melt a narrow band of it, move that band slowly from one end of the bar to the other, and let the contaminants do the work for you. Most of them dissolve more readily in liquid germanium than in solid germanium, so they stay in the molten band and travel with it, collecting at the far end. Then you cut the far end off. Then you run it again.
Zone refining, as the method came to be known, brought germanium to roughly one wrong atom in ten billion. The Computer History Museum's way of putting that is better than anything I could write: a single grain of salt in a railroad carload of sugar. The detail I keep returning to is the division of labor. Growing the crystal was the visible achievement. Purifying it took more passes, more equipment and more years, and without it the crystal was worthless.
The idea, and the half of it nobody is building
That split is on my mind because of a proposal about design systems that I think is correct, and that I also think will fail in a specific and predictable way if we build it the obvious way.
Here is the proposal. Today, when an AI agent needs to build something using your design system, it asks the system questions and the system answers. Traffic runs one direction. Brad Frost describes the prevailing version of this well, where the agent is "deliberately constrained to using the high-quality design system materials," and the system is the fixed thing doing the constraining. Suppose it ran both ways, so that an agent asking a question also leaves something behind, and the system ends up knowing slightly more than it did before the question was asked. Over a year, the system grows out of its own use, one deposit at a time, instead of being assembled in planning cycles.
I think that is right. I also think growing it is the easy half, and that the hard half is the one currently missing from every version of this I have seen described.
Most of what a design system knows is about pairs of things
Ask what a design system contains and you get an inventory: components, tokens, patterns, guidelines. That part is documented well, because it is easy to document. Each item gets a page.
The knowledge that costs a team real time is not about any single item. It is about how two of them relate. Which component replaced which, and in what release. Which component commits you to a spacing decision you never consciously made. Which two components must not be nested, even though nothing in the code prevents it. Which of two perfectly valid options is the correct one when the action cannot be undone.
Almost none of that is written anywhere durable. It lives in review comments, in a thread from March, and in the working memory of two or three people who have been around long enough to remember why.
A knowledge graph is a way of storing information that treats those relationships as records in their own right, rather than as sentences buried in a page about one component. The practical consequence is small to describe and large in effect: if a relationship is its own record, it can carry its own history, meaning who decided it, what evidence they had, and whether it still applies.
Almost nothing in current tooling works this way. Meta's Astryx design system, open-sourced in June, publishes a machine-readable catalogue telling an agent exactly what each of its components will accept. That is genuinely useful, and it describes one component at a time. There is nowhere in it to record "prefer this one over that one when the user cannot undo the action."
What it looks like for a system to learn from being used
Picture a designer, or an agent working on their behalf, building a flow where someone deletes a shared workspace. It asks the design system what to use for a destructive confirmation. The system returns two components that both technically fit, because nothing on file says which is right. The agent picks one. Someone catches it in review, and a senior designer explains in a comment that the other is correct, because it requires a deliberate second action rather than a reflexive click.
Today that comment is where the knowledge stops. It helps one person, on one screen, once. Two quarters later somebody else asks the same question and generates the same comment.
In a system that writes back, that exchange leaves a deposit: a candidate rule saying this component is preferred over that one for irreversible actions, carrying the review comment as its evidence and a named person as its author. Ask the question often enough, settle it in review often enough, and the system ends up holding the answer.
The relationships I listed above are exactly the ones that never get documented, because documenting them requires somebody to make a ruling that two teams may not like. Growth driven by usage routes around that meeting entirely, which is most of the appeal.
Why growth on its own degrades the system
A write-back system feeds on its own output. The agent reads the rules, produces a new rule partly on the basis of what it read, and files it for the next agent to read. Something is learning from a slightly degraded copy of itself, over and over, the way a photocopy of a photocopy loses detail.
There is direct research on what that does. In 2024, Ilia Shumailov and colleagues published a paper in Nature on model collapse: what happens to a generative model trained on material produced by earlier generations of itself. Their central finding is that the damage is not spread evenly. It starts at the edges of what the model knows. The rare cases go first, because too little evidence supports them to survive each round, which the authors describe as the model "losing information about the tails of the distribution." Only later does the common material start to degrade.
They are direct about why they consider this a fairness problem rather than a technical curiosity. Low-probability events, they write, "are often relevant to marginalised groups."
The rare rules in a design system are the accessibility accommodations, the interaction patterns that exist for one regulatory requirement on one product, the component that only makes sense for a small population of users. They are rare precisely because few people ask about them. Any rule that promotes a candidate once enough people have asked about it will drop those first, while reinforcing whatever was already common.
The reporting will look excellent the entire time. Coverage rises, because the system now answers the questions people actually ask. Unresolved queries fall. There is no line on the dashboard for rules the system quietly stopped believing.
A system that moves when you look at it
The best case against all of this is that it destroys the thing a design system exists to provide.
A design system earns its keep by being a fixed point. Teams that never speak to each other still converge, because they are all consulting the same unchanging reference. If that reference rewrites itself as a side effect of being consulted, the guarantee is gone. Two teams ask the same question two months apart, get different answers, and cannot tell whether the system changed its mind or they phrased it differently. That is worse than out-of-date documentation, which at least fails identically for everybody.
I think this is answerable, though not for free. A system like this has to retire rules rather than erase them, so that every rule carries the date it began applying and the date it stopped, and you can always reconstruct what the system would have told you last March. That is not speculative. Agent memory tools already do it. Zep's Graphiti engine marks a contradicted fact as no longer valid instead of deleting it, which is precisely what lets it answer questions about earlier states.
Where my own case is thinnest: I have not found anyone who has run this on a large production design system and published what happened. The failure mode I am describing is borrowed from an adjacent field, and borrowed evidence deserves less confidence than the direct kind.
The three controls
Zone refining suggests what the missing half looks like, and it comes down to three controls, none of them exotic.
The first is a fixed vocabulary. Before anything is permitted to write, decide the small set of relationship types the system will accept: replaces, requires, excludes, preferred-when, plus whatever your system genuinely needs. Anything that doesn't fit is refused rather than absorbed. A crystal needs a seed to grow around; without one, the same material still solidifies, just into many small regions with no order between them.
The second is a rate limit. One question should not produce one rule. A candidate should need corroboration before it hardens, whether that means several independent questions landing on the same relationship or one question plus a named person confirming it. Growth rate and defect density trade against each other, which is why some crystal growth is deliberately run at millimetres per hour.
The third is the pass nobody has budgeted for. Someone, on a schedule, with their name attached, reads what accumulated, keeps what held up, and cuts off the contaminated end. That person has to weight the evidence rather than count it: a rule a person decided is a different kind of thing from a rule an agent proposed, and human decisions should not expire because traffic was light.
If you want a single question to carry into your next system review, try this one. What does our design system know today that nobody told it? An answer of "nothing" means it isn't learning, and every question it fielded last quarter was evidence thrown away. An answer of "quite a lot, and we're not certain what" means you have built the growing half and not the purifying half.
Conclusion
Letting agents write back to a design system is a good idea, because ordinary use is the best evidence a systems team has about what the system is missing, and today that evidence evaporates the moment a question gets answered. But growth is the easy half. A system that accretes from its own traffic drifts toward whatever gets asked about most, and the rules protecting small groups of users are by definition the ones asked about least, so they thin out first while every coverage metric improves. The failure is quiet by construction. The fix is not more automation. It is three unglamorous controls: a fixed vocabulary for what a rule is allowed to say, a bar of corroboration before a candidate hardens, and a named person who decides what stays. Pfann's crystals were never limited by how fast they grew. They were limited by how well anyone could get the contamination out.
