Glossary

The vocabulary for an AI-native design practice. Traditional design systems were made to be looked at. These terms describe systems built to be read, by your agents and not just your team.

The design context layer, defined.

The words in this category are still settling, and the loose ones are doing damage. "AI-ready design system" gets used for a Figma library with a plugin, for a token file in JSON, and for a system an agent can actually query and verify against. Those are three different things with three different failure modes, and a team buying the first while expecting the third finds out two quarters later.

These definitions are written to be checkable rather than flattering. Each one opens with a sentence that stands on its own, then says where the thing shows up in practice and what it is commonly confused with. Where an argument sits behind a definition, the entry links to it.

Design context layer: A design context layer is a machine-readable layer of design context (tokens, components, patterns, and the rules for using them) that AI coding tools consume while they generate UI. It sits between a design system and the agent writing code: the system holds what exists, the layer also holds when to use it and why, in a form software can query. The category Aestheria defines, and the reason a generated screen can be on-system rather than merely plausible. The category, in full
AI-readable design system: An AI-readable design system is a design system structured for machine consumption rather than human browsing: tokens with usage descriptions, components with their states and constraints, an agent context file, and an MCP or API contract. The test is not whether an agent can see the files. It is whether the agent can resolve a decision from them without inventing the missing half. Most design systems fail that test while looking complete, because their real content is a documentation site written for people. Point your agent at one
Machine-readable design system: A machine-readable design system exposes its tokens, components, and rules in a structured, parseable format (JSON, CSS custom properties, or an API) so software can read and apply them, not only people. It is the format half of an AI-readable design system: necessary, and on its own not sufficient. A JSON file of 400 tokens tells an agent which colours exist and nothing about which one belongs on a card border. What the tools return
Design system MCP: A design system MCP is a design system exposed over the Model Context Protocol, so agents can query tokens, components, patterns, and rules on demand during code generation. The difference from a file in the repository is when the context arrives: an MCP server answers mid-task, with the current version, across every project connected to it, instead of being pasted into a prompt and going stale. It also gives the system a place to put verification, so an agent can check its own output before a human reads the diff. Eleven tools, none of which write UI
Agentic design system: An agentic design system is one built for agents to act on, not just read: every component ships the context an agent needs to use it correctly, and the system can verify what was produced. That means naming conventions and usage rules, the states a component ships, the conditions it should not be used in, and a check that returns specific violations rather than a pass or fail. The distinction from an AI-readable system is verification: readable means the agent can consume it, agentic means the system can answer back. What one actually needs
AI codegen continuity: AI codegen continuity is design intent surviving across prompts, files, editors, sessions, and models, so the tenth generated surface reads as the same product as the first. It is the property that fails first in AI-assisted UI work and the last one anybody measures. Continuity is not consistency of style; it is the same decisions being reachable and made the same way every time, by whichever agent happens to be holding the task. Portable tools, unportable taste
Design system drift: Design system drift is the gradual divergence of generated UI from the intended system when AI tools lack structured design context. It accumulates rather than breaks: a hardcoded grey here, a reinvented dropdown there, a page with no empty state, each one a two-minute fix nobody prioritises. Drift is not the model misbehaving. It is an unconstrained process doing what unconstrained processes do, which makes it an authorship problem rather than a generation problem. Why drift is an authorship problem
Semantic token: A semantic token names a design decision by its purpose rather than its value: --color-border-primary, not --grey-200. Purpose-named tokens are what make a theme switch a data attribute instead of a refactor, and they are the single most useful thing a design system can hand an agent, because the name carries the decision. A palette of raw values hands over the paint and keeps the reasoning. How the layers stack
AGENTS.md: AGENTS.md is an open convention for a repository file that gives AI coding tools project context, readable by any agent rather than one vendor's. It is the cross-tool twin of a CLAUDE.md or a .cursorrules file. Like any context file it is a pointer: it tells an agent that a design system exists and roughly where to look, and it cannot itself be the system. What it points at decides whether the instruction resolves or gets interpreted. What travels and what does not
Skills (SKILL.md): A skill is a packaged set of instructions in the open SKILL.md format that an agent loads when a task matches it, carrying judgment rather than inventory. In design work, skills are where the decisions live that a token file cannot encode: which layout a page of this kind takes, which states a screen owes its user, when a confirm step is required. Aestheria ships six (Aria, Atlas, Doric, Mira, Umbra, Aura) as editable files, because the judgment they carry should be your team's, not a vendor's. Judgment, as a file
Generative UI: Generative UI is interface produced at request time by a model rather than laid out in advance by a person, from a task-specific panel to a whole screen assembled for the moment it is needed. It became usable when it stopped inventing components and started composing an existing system, which is the same shift this vocabulary is about. Generated is not the opposite of designed; ungoverned is. When it got good
AI-native SaaS: AI-native SaaS is enterprise software built around delegation and supervision rather than manual operation: the user sets intent, agents execute, and the interface exists to make what happened legible, correctable, and accountable. The visible consequence is that CRUD screens and long forms shrink while approval, review, provenance, and exception surfaces grow. It is not "no UI". It is a different UI, with a different set of jobs. What shrinks, what grows
Starter context: Starter context is a complete design system shipped as a starting point, meant to be edited into your product rather than adopted whole. It answers the chicken-and-egg problem in this category: most tools that make design context readable begin by asking for a design system you may not have. The distinction that matters is ownership, not quality. Starter context you cannot edit is a template; starter context you own is the first version of your system. Why it ships complete