THE CATEGORY · FIVE APPROACHES, AND A SIXTH
AI-NATIVE DESIGN SYSTEMS
The phrase is being used for at least five different things. They are not competing definitions of one idea; they are answers to different questions, and it is worth knowing which question you have.
What is an AI-native design system?
A design system whose rules, components and design intent are usable by AI systems as well as by people. In practice the term covers at least five approaches: an existing design system exposed to agents as a context engine (Atlassian); a machine-readable specification of rules a model reads before generating (Geeklego); markdown design instructions written for coding agents (Didot); a semantic control plane that compiles existing design knowledge into contracts and evidence (Aiko); and tokens packaged to travel inside a prompt (AI UX Playground). HAUSE is a sixth kind: a vocabulary of semantic acts for interfaces an AI composes.
Four of these make an existing design system legible to AI. The question underneath is what vocabulary an AI should use when it is the one deciding how to communicate.
EACH IN ITS OWN WORDS — QUOTED AND LINKED, AUGUST 2026
An existing enterprise design system becoming a context engine
Structured context files, an MCP server, AI skills, and semantic foundations in tokens and components so agents can read and reason about the system's structure.
“context files that guide decision-making”
Rules a model must read before it generates
A three-tier token architecture, a machine-readable spec of 45 never-do and 49 always-do rules, six agent skills and 81 components — enforcement rather than documentation.
“define the system first. Let AI build from it, not around it”
Design instructions a coding agent can follow
Markdown files — DESIGN.md for visual identity, SKILL.md for design reasoning, WORKFLOW.md for agent process — written for how AI tools read rules rather than for human browsing.
“A design system your agent really understands”
A semantic control plane over knowledge that already exists
Ingests design files, component code, docs, tokens and past decisions into a Canonical Design Graph, and projects scoped contracts an agent can use and evidence a team can verify.
“scoped contracts agents can use, and evidence teams can verify”
A design system that fits in a prompt
Tokens, type and components packaged as exact specifications a model can carry into a generation — hex values, sizes, which components exist.
“tokens, type, and components that can travel in a prompt”
WHAT THEY HAVE IN COMMON
All five start from a design system that already exists and make it readable by something that is not a person: as context, as rules, as a graph, as a prompt payload. The unit of work stays the component — a Button, a Dialog, a token tier — and the AI's job is to use them correctly. That is a real problem and these are real answers to it.
CLAIM
HAUSE is answering a different question: not how an AI reads a design system, but what vocabulary it should choose from when it is deciding what to communicate.
Its primitives are not containers made legible — they are named acts: a Claim that owes evidence, an Evidence row that shows what refuted it, a Refusal that declines to assert, an Answer, a Comparison. 35 of them, chosen by naming the act rather than the shape. Marked ongoing rather than settled, because the claim that this is a materially different category rests on a young library with two consumers and one author.
SOMEBODY ELSE ARRIVED AT THE SAME PLACE FROM ANOTHER DIRECTION
Adam Kinney's essay on AI-native design reaches the same territory without naming the same things, and it is worth reading beside this. It argues that these systems are behavioural grammars rather than component libraries, and that what is missing is an explicit vocabulary for epistemic state. That is the gap HAUSE built forms for — and independent arrival at a problem is better evidence that the problem is real than one project asserting it.
Adam Kinney — Eight Dimensions of AI-Native Design
AI-native design systems are behavioral grammars for systems that don't have predetermined states.\n\nThe design system needs an explicit vocabulary for epistemic state: certainty, uncertainty, action, caution, error recovery.
WHAT HAUSE DOES NOT DO
It has no MCP server, no Figma ingestion, no token pipeline, no agent skills, and no component coverage for the transactional layer — no buttons, inputs, tables or navigation. If the problem is that a coding agent keeps misusing an existing component library, the systems above solve that and HAUSE does not. It is the semantic layer above them, and it expects to sit beside a UI framework rather than replace one.
EVIDENCE
The semantic vocabulary is selectable by a model that has never seen it
CHOOSING-1: 124 preregistered cases written without HAUSE's vocabulary, scored by fresh contexts with no access to the site — 122 of 124 correct, including 30 of 30 near-neighbour traps. Published with the finding that the comparison it was built to make was void.
The deterministic projection of that vocabulary works
8 of 124 on the same cases, and 3 of 12 on fresh selections after being rebuilt onto records. Published as it came out.
Adoption is broad
Two consumer sites, one author, version 0.1.0. 18 of the 35 forms name a single consumer as their origin, which the provenance record calls the honest weakness of a young design system.
The argument this page compresses, the grammar it refers to, and the evidence behind both.
PUBLISHED 31 AUG 2026 · VERSION 1.0
CITEsite build 3ee5339 · built 2026-09-09
CITE THIS
Article · 1.0
Hay, C. (2026). AI-native design systems: the approaches, and where HAUSE sits (Version 1.0). hause.design. https://hause.design/ai-native-design-systems
A landscape written to flatter one entry in it is worth nothing to a reader choosing between them — so the quotes are theirs and the absences are ours.