Agentic Design Systems Are Contracts, Not Libraries
And most teams are quietly building the wrong half of one
There are two conversations happening about design and AI right now, and they are pretending not to be the same conversation.
The first comes from inside the design-system community. It says: components are becoming contracts. Tokens need intent, not just values. Agents need to read the system, not just consume it. The system is no longer infrastructure for humans. It is infrastructure for machines.
The second comes from Microsoft, Google, and every team rebuilding a flagship product around an LLM. It says: the interface itself is dissolving. Chat is the new shell. Windowing is becoming dynamic. The user is becoming an “agent boss.” The UI flexes to match intent rather than the other way around.
Both descriptions are correct. Both are incomplete on their own. And the gap between them, the seam where one ends and the other begins, is where the actual work of the next five years lives. It is also the gap most enterprise teams are quietly failing to bridge, because they are treating it as either a tooling problem or a UX problem, when it is really a contract problem.
What both sides are circling without quite naming is the same thing. The LLM is becoming the new experience OS. Not a channel, not a feature, not even a “frontend layer.” An operating system, in the original sense: the substrate that mediates between intent and action, that decides what gets surfaced, that holds the rules about what is allowed, that brokers between the user and everything else. Your design system either runs on top of that OS as readable, contractible infrastructure, or it gets bypassed entirely while a model improvises your brand for you.
I want to lay out what that contract is, why it matters more than any specific tool or model, and what changes when you start designing for it.
Two halves of the same elephant
Look at how design-system thinkers describe the shift. The argument, in compressed form, goes like this: AI does not need a component library, it needs a contract. A button is no longer <Button variant="primary">; it is a structured set of rules about intent, accessibility, when to use, when not to use, what the safe variants are, and what requires human escalation. Tokens stop being hex codes and start carrying purpose: this color is for primary action, not decoration; avoid it for destructive flows; preserve this contrast ratio. The point is governed autonomy: agents that propose, humans that approve, systems that validate.
This is the supply side of the agentic design conversation. It asks: what does the design system have to expose so that an agent can read it, reason with it, and act on it without making the product worse?
Now look at how Microsoft frames the M365 Copilot redesign. They describe a hero experience reinvented around chat-based interaction, dynamic windowing, intent-driven computing, and a designer’s role shifting from making interfaces to orchestrating coherence across nondeterministic systems. Jon Friedman’s earlier piece on design systems for the AI era pushes further: the system has to handle verbs over icons, natural language alongside GUI, adaptive controls that bend to context, agents that collaborate on the user’s behalf.
This is the demand side. It asks: what does the surface have to do so that a human can express intent, see what the system is doing, and trust the result?
Each side, taken alone, produces something incomplete. A perfectly machine-readable design system with no coherent surface is a database. A beautifully fluid intent-driven UI with no contracts underneath is theatre. It works in the demo and breaks in production. The interesting work is in the middle, and the middle has a name: orchestration.
What orchestration actually means (and what it is not)
Orchestration has become a soft word. It gets used for everything from “we have a few agents talking to each other” to “we put a chat box in front of an API.” Both of those are useful, neither of those is orchestration.
Orchestration is the layer that:
Translates user intent into a sequence of agent actions.
Reconciles those actions against system rules: design contracts, brand constraints, accessibility, security, governance.
Decides which actions execute autonomously, which require human approval, and which must be refused outright.
Maintains a coherent surface so that the user can see what is happening, intervene, and trust the outcome.
Closes the loop with telemetry, so the system gets better at points 1 through 4 over time.
Point three is where most teams stop. Point four is where Microsoft is investing. Point five is what almost nobody has yet. And points one and two are where the design system (if it has been rebuilt as a contract) earns its keep.
In my team, the first question we ask on any new engagement is not “what agents do you want to build.” That question is downstream. The first question is: “what is the smallest unit of decision your system needs to make on its own, and what does it need to know to make it correctly?” Almost every interesting answer comes back to either the design system or the surrounding governance scaffolding. Almost none of them come back to the model.
The model is the easy part. The contract is the hard part.
The third paradigm nobody is designing for yet
There is a quieter shift happening underneath both the design-system conversation and the Microsoft-style surface conversation, and it changes the math on everything.
For most of the history of digital design, there has been one paradigm: a human reads a screen and makes a choice. The work of design has been to make that screen legible, that choice clear, that flow coherent. The agentic shift introduced a second paradigm: a human talks to an agent and delegates a choice. This is the one Microsoft is investing in, the one the M365 Copilot redesign is built around, the one most enterprise pilots are exploring. The agent reads the screen on the user’s behalf.
The third paradigm is the one almost no one is designing for yet, even though it is starting to ship: an agent talks to another agent and negotiates an outcome on behalf of two parties who never see a screen at all. A consumer’s personal agent contacting a brand’s agent to renegotiate a plan. A procurement agent talking to a vendor agent to compare options against a constraint list. An advisor agent calling a service agent to schedule a complex appointment with downstream dependencies. The user does not browse. The brand does not present. The interface is the protocol.
This is not science fiction. It is the logical end state of the trajectory the major platforms are already on, and the early versions of it are operational this year in commerce, financial services, and telco. Once a user trusts an agent to act on their behalf, the agent does not need pretty pages to make decisions. It needs structured, queryable, contractible information about what is offered, what is allowed, what is true, and what is differentiable.
This is the moment the contract argument stops being about productivity and starts being about survival. If your brand only exists as a screen, the agent will skip the screen. If your brand only exists as a campaign, the agent will skip the campaign. What the agent will not skip is structured truth about your products, services, prices, policies, and value, exposed in a format another agent can negotiate against. The brands that lose in the agent-to-agent economy are not the ones with bad design. They are the ones whose design system never learned to speak to anything that was not a human.
The four contract layers I am about to describe are not just about making your own agents useful. They are about being legible to agents that do not work for you. That is a different stakes ladder, and it changes which work matters.
Components were always contracts. We just got lazy about writing them down.
The mental model that needs to shift is not about agents. It is about how we have been treating components for the last decade.
A component has always been a contract. Every reusable Button in every design system ever written carried implicit promises: this is the primary action, use it once per flow, do not use destructive styling without confirmation, maintain this contrast, preserve keyboard navigation, here is how it behaves on touch, here is what happens when it is loading. Those promises lived in documentation pages, Figma annotations, Slack threads, the heads of three senior designers who had been at the company long enough to remember why decisions were made, and code review comments from two years ago.
That arrangement worked when the only consumer of the system was a human designer who could ask another human. It does not work when the consumer is an agent, because the agent cannot ask. It will either find the rule encoded somewhere it can read, or it will guess. And when it guesses, it will guess plausibly, which is worse than guessing badly. Plausibly wrong output passes review more often than obviously wrong output.
So the work is not to invent contracts. It is to write down the contracts that have always existed informally, in a structure that both humans and agents can read. Intent. Variants. Constraints. Accessibility. Anti-patterns. Escalation rules. Telemetry hooks. Ownership. The system becomes its own documentation, and the documentation becomes executable context.
If you have ever wondered why some teams move ten times faster on AI projects than others despite having the same models, the same designers, and the same Figma libraries, this is why. The fast teams have already paid the contract tax. The slow teams are paying it now, under deadline pressure, while also trying to ship.
The shift Microsoft is actually making
The M365 Copilot redesign is the most visible example of demand-side rethinking right now, and it is worth being precise about what they are doing, because most coverage gets it wrong.
They are not “putting chat at the front.” They have moved chat from a feature inside many apps to a primary surface that can route into many apps. The structural inversion matters: apps used to be the destination and chat was a feature; now intent is the destination and apps are the means. This is what intent-driven computing means in practice.
They are not making the UI “more conversational.” They are introducing a windowing model that flexes between modes: side-by-side chat against a Pages document, editing tools that appear in the moment when an AI-generated image needs refinement, an accordion architecture that collapses when you need focus and expands when you need control. The interface is no longer a fixed set of screens you move between. It is a surface that reconfigures around what you are trying to do.
They are not “adding AI to Fluent.” They are evolving Fluent toward what Friedman calls a system of systems: one that has to express verbs as well as nouns, actions as well as objects, adaptive controls as well as fixed ones, agents as well as components. The design system itself is becoming a substrate that can describe behavior, not just appearance.
And they are not just shipping features. They are signaling a methodological shift: designers move from making things to making sense of things. From producing interfaces to orchestrating coherence. From component factory to system architect.
If you are a designer reading this and that last sentence feels uncomfortable, sit with the discomfort. The discomfort is the point.
The four contracts your system needs
The agentic design system conversation often gets stuck at the component level. That is too narrow. There are four contract layers, and most teams have only seriously written one of them.
The component contract. This is the one most teams understand. What is the component, what are its variants, when do you use it, when do you not. Intent, accessibility, anti-patterns. The work here is mostly translation: take what your senior designers know implicitly and make it readable. Start with your five most-used components. A markdown file is enough.
The token contract. Beyond hex codes. Each semantic token carries purpose, valid uses, invalid uses, accessibility requirements, and the relationships that bind it to other tokens (the responsive variants, the dark mode pair, the high-contrast fallback). Polaris and Carbon are the closest production examples; most enterprise systems are five years behind. The work here is structural: most token systems were designed for CSS, not for reasoning, and they need a metadata layer added on top.
The interaction contract. This is the one that breaks most teams when they try to introduce agents. What are the verbs in your system? Not the visual states. The verbs. What does “submit” mean here, what does “summarize” mean, what does “approve” mean, what does “share” mean? Each verb has rules: what data it can touch, what consent it requires, what undo is available, what telemetry it emits, what failure modes it has. In an agentic system, agents call verbs the way developers call functions. If your verbs are not specified, your agents are improvising.
The governance contract. What is safe to automate? What requires review? Who owns what? What are the audit trails? What are the rollback paths? What are the kill switches? This is the layer that turns “agentic” from a marketing word into an operational reality. Most teams want to skip this because it feels like compliance overhead. It is not. It is the difference between agents you can deploy and agents that stay in the lab.
You do not need all four to be perfect. You need all four to exist. A weak governance contract is recoverable. A missing one is not.
What I have learned shipping this
A few patterns from the engagements that have actually worked, and a few from the ones that have not.
Start with the boring agents. The first useful agent is almost never the impressive demo agent. It is the one that watches your design system for token drift and opens cleanup pull requests. The one that audits your Figma file for detached instances and missing component descriptions. The one that runs accessibility checks before merge and fails the build when a contrast ratio drops. These are unglamorous, they are measurable, and they build the organizational trust you need before anyone gives you permission to ship a customer-facing agent. Boring is where trust starts.
Treat the design-to-code category as already collapsed. Anima, Locofy, Builder, v0: they all solved one half of a problem (Figma to React) using their own heuristics. The Model Context Protocol made that half a commodity. A general-purpose coding agent can now read Figma, read your codebase, read your tokens, and produce code that survives review, provided your design system gives it enough context. The category is being absorbed into agents that were already in the workflow. The question is no longer which point tool wins. It is whether your system is readable enough to be useful to any agent.
The orchestrator is a real job and a real role. The hardest hire on an AXD engagement is not the designer or the AI engineer. It is the person who can hold the orchestration logic in their head, who understands the design contracts, the agent capabilities, the governance constraints, and the user flows, and who can make decisions about where autonomy belongs and where it does not. This role does not have a stable title yet. It will. Some teams are calling it agent designer; others, experience architect; others, AI orchestrator. The label does not matter. The seat matters.
Adaptive does not mean manipulative, and the line is thinner than your roadmap admits. Adaptive UI is the demand-side promise everyone wants to make. The system can flex to viewport, platform, input mode, locale, accessibility setting, motion preference. All of that is reasonable and overdue. The system can also flex to inferred hesitation, conversion likelihood, emotional state, or behavioral vulnerability. That is not adaptive UI, that is manipulation with better tooling. Every team I have worked with on adaptive systems has reached the moment where someone on the product side proposes a “hesitation-aware CTA” and the room has to decide whether that is service or coercion. The right answer is almost always coercion, and the systems that do not have an ethics layer in the design contract will find this out the slow, expensive way. Build the layer before you need it.
Structure beats prompts. Always. The single most consistent finding across every team I have worked with is that prompt quality is a rounding error compared to context quality. A weak prompt against a well-structured design system produces better output than a brilliant prompt against an unstructured one. This is not intuitive. Prompting feels like the thing you can control, while structure feels like infrastructure. But the leverage is in the structure. The prompt is the steering wheel. The structure is the road.
What this means if you are a designer
The framing that gets repeated, that designers will become orchestrators rather than makers, is correct. It is also incomplete in a way that flatters the people repeating it. The truth is more uncomfortable.
You will spend less time producing variations. The system will do that. You will spend less time writing documentation. Agents will do that, and humans will review. You will spend less time auditing for consistency. That is exactly the kind of work background agents are good at.
You will spend more time on the things that do not have a generative shortcut: defining intent, setting quality bars, deciding what the system should refuse to do, owning the taste decisions that brand and product strategy depend on, deciding when to evolve the system rather than follow it. You will spend more time on governance, more time on ethics review, more time on telemetry interpretation. You will spend more time on the parts of the craft that were always the highest-leverage parts but were buried under production work.
This is good news for designers who like thinking and bad news for designers who like the safety of producing. The middle of the career ladder, the senior individual contributor who is great at making things and rarely has to make decisions, is the role that is being squeezed hardest. The most junior end is squeezed too, because the tasks that built up early-career muscle are the ones agents do best. The defense, for both ends, is the same: stop optimizing for output, start optimizing for judgment.
And this part matters. Judgment is not a vibe. It is the accumulation of context, principle, taste, and consequence-thinking that lets you make the call when the system cannot. It is built by doing real work in real systems with real stakes. The teams that will produce the next generation of senior designers are the ones that put junior people on agentic projects early and give them ownership of contract decisions, not the ones that protect them from the change.
What to do this week
Two things, and I mean this week. Not this quarter.
Pick one component and write its contract. Your most-used one. Five sections: intent, variants, rules, accessibility, anti-patterns. One page, markdown, checked into the repository. The exercise is not the document. The exercise is the conversation it forces. Half of what you will discover is that the team disagrees about what the component is for. That disagreement is the contract. Resolve it, write it down.
Pick five tokens and add intent metadata. Not all of them. Five. The ones you already know are getting misused. For each one, write: what it is for, what it is not for, what the accessibility requirement is. JSON, README, doc page, whatever you already have. The point is not the schema. The point is that you now have one token group that an agent could safely reason about, and four hundred that it cannot. Next week, you do five more.
This is not a transformation project. It is a habit. The teams that compound on this for six months are the ones that look like wizards at the end of the year.
What it costs to not do this
I have been making a structural argument, and structural arguments are easy to nod at and easy to defer. So before the closing point, the concrete one.
Three things happen to brands that ship into the agentic era without contractible design systems. They are happening already, in the early agentic flows that are live this year.
Narrative loss. Agents summarise your brand for users. They pick which features to highlight, which reviews to weight, which use cases to surface. If the only place your story lives is in marketing copy and product pages designed for humans, the agent will reconstruct your story from whatever fragments it can stitch together, and the version it tells will not be the version you would have told. The brands that keep narrative control are the ones that expose structured truth about themselves in formats agents can read. The brands that lose it are the ones still optimising landing pages.
Commoditisation. When agents compare options on behalf of users, they default to rational dimensions: price, speed, features, availability. Emotional resonance and brand affinity collapse into rounding errors unless you have given the agent a structured reason to weight them. If your differentiation lives only in the look and feel of your interface, the agent does not see it. Differentiation that is not encoded is differentiation that does not exist, from the agent’s point of view.
Auto-switching. Switching costs in the agent-to-agent economy approach zero. The agent does not feel loyalty, does not have habits, does not remember the time customer service was helpful. It optimises against the constraints the user gave it. Loyalty in this world is not a feeling. It is whatever structured signal you have given the agent about why you are worth choosing repeatedly. If you have not built that signal into your contract layer, your retention numbers are running on borrowed time.
None of these are speculative. All three are happening now in the early agentic commerce experiments, and the lead time between “first agent flows in your category” and “majority of decisions routed through agents” is shorter than the time it takes to build a real design-system overhaul. The brands that started this work two years ago are about to look prescient. The brands that start in eighteen months are going to be doing it under crisis conditions.
The part that has not been said yet
Here is what I think is underdiscussed in both the design-system conversation and the Microsoft-style demand-side conversation.
Both are talking about agents and humans. Neither is talking enough about time. The agentic shift is not just structural. It is temporal. The design system you ship today has to be readable not just by today’s agents but by the next three generations of them, which will be smarter, faster, and operating against constraints you cannot yet predict. The contracts you write now are an investment in a future where the cost of misalignment compounds, because agents act faster and at higher volume than humans ever did. A poorly specified component shipped today produces twenty mistakes a year when humans use it; it produces twenty thousand when agents do.
This is the actual stakes. Not “AI is coming for design jobs,” which is a tired framing that misses the point. The real stakes: design decisions are about to be executed at machine speed and machine scale, and the systems that did not get the contracts right are going to discover that error at machine speed and machine scale too.
The design system is not becoming infrastructure for agents in some abstract future sense. It is becoming the place where the consequences of unclear thinking get amplified. That is not a tooling problem. That is a craft problem. And the discipline that takes craft seriously, that has always taken craft seriously, is design.
The contract is yours to write. Write it like it matters, because it does.