In 1950 Bell Labs had a working transistor and no dependable way to make more. The problem was purity. A transistor works by adding tiny, controlled amounts of impurity to a semiconductor. It only works if you start from a material with almost none in it. Growing germanium as a single crystal was already solved. Getting the contamination out wasn't.
William Pfann stopped trying to purify the whole bar at once. He melted a narrow band and moved it slowly along the length. Most contaminants dissolve more readily in liquid germanium than in solid, so they ride inside the band and collect at the far end. You cut that end off, then run it again. Zone refining brought germanium to about one wrong atom in ten billion. The Computer History Museum glosses that as a grain of salt in a railroad carload of sugar. Growing the crystal was the visible achievement. Purifying it took more passes and more years, and the crystal was worthless without it.
What a crystal knowledge graph is
A crystal knowledge graph is a design system that adds to itself while it's being used. An agent asks it a question, the exchange leaves a deposit behind, and the system ends up holding a rule it didn't hold that morning. Growth comes from traffic instead of from planning cycles. That's the analogy cashed, and the last you'll hear about germanium. One part carries over: deposition and purification are two different jobs, and only one of them runs by itself.
Brad Frost describes today's arrangement accurately. The agent is "deliberately constrained to using the high-quality design system materials," so the system constrains and the agent complies. Traffic runs one direction. Your system learns nothing from being consulted, which means every question it answers is evidence you collected and threw away.
Writing back is the right correction, and it fails in one specific way. A system that accretes from its own traffic drifts toward whatever gets asked about most. The rules protecting small groups of users are the ones asked about least, so they erode first, and the person who needed that accommodation pays for it.
Most of what your system knows is about pairs of things
Your design system documents its inventory well: components, tokens, patterns, guidelines. Each item gets a page, since each one is easy to describe on its own.
The knowledge that costs your team time is about how two items relate. Which component replaced which, and in which release. Which component commits you to a spacing decision you never made. Which two must never nest, even though nothing in the code stops you. Which of two valid options is right when the action can't be undone.
A knowledge graph stores those relationships as records rather than sentences. That matters, since a record carries its own history: who decided it, what evidence they had, and whether it still applies. A sentence buried in a component page carries none of that, so the reason dies before the rule does.
Almost nothing shipping today works this way. For example, Meta's Astryx design system, open-sourced in June, publishes a machine-readable catalogue of what each component will accept. It's useful, and it describes one component at a time. There's nowhere in it to record "prefer this one when the user can't undo the action."
What a deposit looks like
Consider a designer building a flow where someone deletes a shared workspace. The agent asks your system what to use for a destructive confirmation. Two components technically fit, nothing on file says which is right, so the agent picks one. A reviewer catches it and explains that the other is correct, since it requires a deliberate second action instead of a reflexive click.
Today that comment is where the knowledge stops. It helps one person, on one screen, once. Two quarters later somebody asks the same question and a reviewer writes the same comment again. That costs your most experienced designers the same twenty minutes every time.
In a crystal knowledge graph that exchange leaves a candidate rule: this component is preferred for irreversible actions. The review comment travels with it as evidence, and so does the reviewer's name. Ask it often enough, settle it often enough, and the system holds the answer instead of the reviewer.
The appeal is real, since those relationships never get documented otherwise. Writing one down means ruling between two teams who each shipped something, and nobody wants to schedule that meeting. Growth from usage routes around it.
Why growth on its own makes the system worse
A crystal knowledge graph feeds on its own output. The agent reads the rules, writes a new rule partly from what it read, and files it for the next agent to read. Each round learns from a slightly degraded copy of the last, the way a photocopy of a photocopy loses detail.
Ilia Shumailov and colleagues measured what that does. Their 2024 Nature paper on model collapse tracked generative models trained on material produced by earlier generations of themselves, and found the damage isn't spread evenly. Rare cases go first. Too little evidence supports them to survive each round, which the authors describe as losing information about "the tails of the distribution." Common material degrades later.
They're direct about why that's a fairness problem rather than a technical curiosity. Low-probability events, they write, "are often relevant to marginalised groups."
The transfer to design systems needs almost no adjustment. Your rare rules are the accessibility accommodations and the patterns that exist for one regulatory requirement on one product. For example, the component that only makes sense for a small population of users. They're rare because few people ask about them. Any bar that promotes a candidate once enough people have asked will drop those first.
Your reporting improves the entire time. Coverage rises, since the system now answers the questions people actually ask. Unresolved queries fall. No dashboard tracks rules the system stopped believing. You find out when a screen reader user reaches a flow that lost its announcement pattern.
A reference that moves
A design system earns its keep by holding still. Teams that never talk to each other converge, since they're all consulting the same unchanging thing. A reference that rewrites itself while being consulted breaks that guarantee. Two teams ask the same question two months apart, get different answers, and can't tell whether the system changed its mind or they asked differently. That's worse than stale documentation, which at least fails the same way for everyone.
So the system must retire rules instead of erasing them. Every rule should carry the date it started applying and the date it stopped, so you can reconstruct what the system would have told you last March. Agent memory tools already work this way. Zep's Graphiti engine marks a contradicted fact invalid rather than deleting it, which is what lets it answer questions about earlier states.
One limit belongs on the record. No published case study runs write-back on a production design system at scale. Model collapse is measured in language models, not in design systems.
The three controls
Three controls separate a system that improves from one that just thickens.
Fix the vocabulary first. Your systems team must decide the small set of relationship types the graph will accept before anything is allowed to write: replaces, requires, excludes, preferred-when. Anything else gets refused. A write path that accepts arbitrary claims produces a pile instead of a system, and nobody can query a pile.
Require corroboration. One question should not produce one rule. A candidate should need several independent questions landing on the same relationship, or one question plus a named person confirming it. Without that bar a single agent's guess becomes a rule, and every later agent treats it as settled.
Name the person who prunes. A design system lead must own a scheduled review of what accumulated, with the authority to cut. That review should weight evidence instead of counting it. A rule a person decided isn't the same kind of thing as a rule an agent proposed, so human decisions must not expire just because traffic was light. Machines do better with speed and scale. People do better with context and nuance, and deciding which rules protect users nobody asked about is a context problem.
If you can't staff that review, don't open the write path. Run the system read-only and keep the log of what agents asked it. The questions are evidence even when nothing gets written back, so you can mine them the quarter you can staff the review.
Conclusion
Letting agents add to your design system is right. Ordinary use is the best evidence you have about what your system is missing, and today that evidence disappears the moment a question gets answered. Growing it is the cheap half. A system that accretes from its own traffic drifts toward the common case. The rules covering small groups of users are the ones fewest people ask about, so they thin out first while every coverage number improves. More automation won't fix that. Fix the relationship vocabulary before you open the write path. Require corroboration before a candidate becomes a rule, and give a named owner a scheduled review with the authority to cut. If you can't staff that review, keep the system read-only and keep the question log anyway. A system that learns needs someone accountable for what it learns.
