Blog
What is a design context layer?
A design context layer is a machine-readable layer of design context: the tokens, components, patterns, and rules an AI codegen tool reads to generate on-system UI. Aestheria is the design context layer for AI-native teams. Here is the category, defined.
The problem it solves
Cursor and Claude Code read your codebase. They do not read your design intent. Ask for a settings page and the agent invents spacing, restyles buttons, and picks colors that almost match the rest of your product. By the fifth screen, the product looks like five products.
The failure is not the model. It is missing context. Design decisions live in Figma files, documentation sites, and the heads of your team: places an agent cannot read mid-prompt. So every generation starts from zero, and your AI redesigns your company every time you open a new chat window.
The cost compounds quietly. Each screen is defensible on its own, so nothing gets rejected in review. The drift is only visible in aggregate, and by the time it is, fixing it means touching forty files instead of four.
The definition
A design context layer packages design decisions in a form machines consume: tokens with usage rules, a component library, patterns, templates, and the conventions that govern them, exposed as files in your repo or over MCP. Not documentation about the system. The system itself, built to be read.
The distinction from a traditional design system is the audience. Design systems were optimized for humans reading documentation. A design context layer is optimized for AI systems consuming context, with humans still editing it. The design system inside is the starter context; the product is continuity.
A complete layer answers four questions in order: what exists, how each piece is used, when to reach for it, and why. Most systems answer the first two well. The last two decide whether generated UI holds together. The glossary has the short definitions for the surrounding vocabulary.
What exists, and what good looks like
An inventory is not a judgment. A list of 443 tokens tells an agent which colors exist. It does not tell it that a destructive action needs a confirm step, that a dense record set belongs in a table rather than a card grid, or that a decision the user cannot undo deserves a side panel instead of a modal.
Those are the calls an agent gets wrong most often, because nothing in a token file encodes them. A layer that stops at assets produces screens that are on-brand and still do not work. Context tells your AI what exists. The rules tell it what good looks like.
Aestheria ships both halves: 443 tokens across 3 themes in light and dark, a component library, 26+ visualizations, and 21+ page templates, plus six skills that carry the judgment. Atlas owns page structure, Doric owns token discipline, Mira owns interaction states, Umbra owns usability and the states most screens forget, Aura owns accessibility, and Aria routes between them. They ship as starter context you edit, not a black box.
How agents read it
Three paths, one source. As files in your repo, where an AGENTS.md at the project root points the agent at tokens, components, and rules. Any editor that reads AGENTS.md works today, with no server and no account.
As skills, using the open SKILL.md format. A skill is a folder holding instructions plus a description of when they apply. The agent loads only the description at startup and pulls the full instructions when a task matches, so a large body of design rules costs almost nothing until something needs it. As of August 2026, Claude Code, Cursor, Codex, Copilot, and more than thirty other clients read the same format.
Over MCP, where the agent queries the library live and updates reach every project without a repo change. That is the right fit when several products share one system. Aestheria for Cursor and Aestheria for Claude Code walk through both setups.
Every path resolves to the same source of truth, so the choice is an operations question rather than a design one. Whichever you pick, the agent composes real components instead of reinventing them, and the next screen belongs to the same product as the last one.
What it is not
It is not a UI kit. A kit is a set of assets a person assembles by hand. A context layer is read by a machine at generation time, and the difference shows up in what happens when nobody is watching.
It is not a rules file. A DESIGN.md or a .cursorrules tells an agent how to behave and points at nothing in particular. A context layer is the thing those instructions point at. The full comparison covers where each one stops.
It is not a Figma library. A Figma file holds design intent in a form built for people to look at. Reading it through MCP helps, but the agent still receives a drawing to interpret rather than a decision already made.
How to tell you need one
Three symptoms, and one is usually enough:
- Two screens generated a week apart use different spacing for the same relationship.
- Your agent invents a token instead of using yours, and the hex is close enough that review misses it.
- Adopting a second AI tool means re-explaining your conventions from scratch in a prompt.
None of these are model problems, and a better model makes each one worse rather than better, because cheaper generation means more surfaces drifting per week. The organizational version of this argument is in The AI-ready organization, and the longer view of where enterprise UI is heading is in Enterprise UI in the AI era.
Setup runs in either direction, repo or MCP. The docs cover both.
Questions
Is a design context layer the same as a design system?
No. A design system is content made for people to read. A design context layer is that content made machine-readable, with the rules and serving (repo files or MCP) an AI agent needs to apply it correctly.
Why do AI coding tools need a design context layer?
Without structured design context, tools like Cursor and Claude Code guess: they invent tokens and drift from your brand a little more every session. With one, they compose your actual system, every prompt.
How does an agent read a design context layer?
Three ways, one source. As files in your repo, where an AGENTS.md points at tokens, components, and rules. As skills, the open SKILL.md format that Claude Code, Cursor, Codex, and Copilot all load on demand. Or over MCP, where the agent queries the same library live.
Is an AGENTS.md file a design context layer?
No. An AGENTS.md is a pointer: it tells the agent where to look and what the conventions are, in prose. The design context layer is what it points at, which is the tokens, components, patterns, and rules themselves, in a form the agent resolves rather than interprets.
Do I need MCP to use a design context layer?
No. Files in the repo work in any editor that reads AGENTS.md or the open SKILL.md format, which today includes Claude Code, Cursor, Codex, and Copilot. MCP adds live updates without a repo change, and it fits best when several products share one library.
Do I need an existing design system first?
No, and that assumption is backwards for most teams. Aestheria ships a complete starter system: 443 tokens across 3 themes in light and dark, a component library, 26+ visualizations, and 21+ page templates. You edit it down to the token as your product matures, instead of building a system before your agent can use anything.