Context before the component

Your design system has a new consumer, and it doesn't see buttons. Agents now assemble interfaces from the same components your teams use, but they read structure and metadata, not layouts. To a person, ambiguity is a judgement call. To an agent it is a blocker, or an invitation to invent a solution of its own. For fifteen years the system served designers and developers, and everyone agreed roughly what it was: foundations, components, tokens, documentation, governance. Add a consumer that reads instead of looks, and every one of those gets questioned at once.

Ask the field now and everyone answers differently: components become structured data; the source of truth is the essence of a component with no implementation; give the model primitives and let it decide; the system is the product; the interface dissolves entirely. Even the people who wrote the old definitions aren't defending them. Around that sits the hype: the component library is dead, design systems are so last year. Nobody is actually killing the library. The tools that generate interfaces well build on components, and the large open source systems are busy making their libraries easier for machines to read. So the library stays. What changes is who it is for, what it ships, and what the people who build it spend their days on.

What the system ships now

So the deliverables grow. Alongside tokens, components and governance, a system now ships two new things. Context is what an agent needs to know about how things are done here. Skills are repeatable, opinionated instructions for how work actually gets done. MCP servers and command line tools follow, so agents can reach the system directly. A useful rule of thumb: if it is for humans, it is documentation; if it is for a model, it is context. Same knowledge, different consumer, different artefact.

That changes documentation more than anything. The polished, hand-written reference site can wait. What can't wait is the knowledge itself: annotations, decision records, the reasons something was ruled out. Keep those human-authored and queryable, and both people and agents can get answers assembled from the sources you maintain anyway. Nothing falls out of date because nothing is duplicated. The format of knowledge turns out to be negotiable. The authorship doesn't.

Eighty per cent is a knowledge gap

People doing this seriously put a model's unaided output at roughly 80 to 85 per cent of the way to production ready, and that number has barely moved in a year. What has changed is what the misses look like. Two years ago a miss was obviously broken. Now it is clean, polished and passes a glance, and it still isn't your component: a variant you don't have, a prop that was invented, a spacing value that belongs to no token.

Usually that isn't the model being bad at its job. It is the model filling a gap, because something wasn't explicit. Design systems had this failure before AI arrived. Docs drift from design, design drifts from code, and teams were losing that fight more often than not with only humans involved. A contributor that fills gaps with complete confidence multiplies the drift.

The consequence is that an AI contributor is only as good as the system's memory. It fails on integrity long before it fails on capability. So build for integrity first.

Context before the component

Most of the industry is retrofitting context onto finished systems: metadata, agent files and servers bolted onto a library that already exists. The alternative is to put the context in before the component exists.

One way to do that is a single reference document per component, with one origin for every fact. When a component is needed, whoever needs it writes down what is true about it: behaviour, accessibility, edge cases, variants, and what was ruled out and why. Plain enough for a product manager to write, structured enough for an agent to turn into tests. Judgement doesn't happen in JSON, and models read human language well.

The document then travels with the component. Design reads it and writes back. Developers read it and write back. The build agent reads it, the documentation agent reads it, and the agent assembling the next page reads it before placing anything. Each new document is written with all the earlier ones behind it, so nothing downstream has to guess which version of the truth is current. That is the memory, and it compounds.

It still drifts, because people maintain it and people are human. The fix isn't to take them out. Pair the document with skills that keep it behaving, and let the people own the judgement.

Where the designing happens

If a document briefs the design and agents do the building, where does design happen? Screen and flow design are already moving into AI-first tools, and that is fine to let go. Component design is where the density of judgement is highest, so it stays on the canvas longest. Not the labour: nobody needs to build a variant matrix by hand any more. What stays is the zoom in: one component at full magnification, where brand expression and craft happen, and where an experiment gets pushed past what is feasible before something reins it in.

Hold that loosely. The pull away from the canvas is real, though much of it is appetite rather than evidence: a new workflow wanted because it is new. It is also worth making sure the shift doesn't quietly become a return to developer-led design.

What a design system is, then

Its place. Features, flows and screens can now be generated on demand: fluid, disposable, probabilistic. But they are generated from something. The components, the tokens, the context and the human decisions are the stable layer everything else orbits. The system is how misbehaving models are kept under control.

What it delivers. Things for people, as before, and now things for machines. The remit grows too. Systems used to own the pieces and leave assembly to product teams, not because assembly didn't belong with them but because nobody had the capacity. With skills, the assembly ships with the parts. Without that, you get seven versions of the same pattern, and more once agents are involved.

The job. A design system always had a second job nobody put on a roadmap: vigilance. Keeping every part in agreement with every other, while the piece you aren't looking at goes stale behind your back. It punishes humans, it is never finished, and teams were failing at it half the time. That job is now delegable. Not the decisions, but the watching: recording changes, flagging drift, carrying feedback from product teams back to the system. Agents don't get bored of it.

What that hands back to people is the part they were hired for: the standards, the saying no, and being answerable for what the system produces. A model can generate the component. It cannot own the responsibility. "The agent decided" is not an answer anyone can stand behind.

Four questions to take back

What does your system actually ship now, and who or what is it for? Which part of the practice would you protect at any cost? What have you already quietly let go? And when the workflow ships something wrong, who answers for it? The last one already has an answer. It is you, and it should stay you.