Designers are missing from the newest design surface
Michael Higgins, October 2026
The screen nobody designed
You ask an AI agent to compare three plans. It does not answer in prose. It renders an interface: a card, a table, a button. The screen is assembled at runtime, shown once, then gone.
Nobody designed that screen. No designer chose the type size or the button color. The agent picked components from a catalog and filled them with data. This is a standard pattern now, not a demo. Google published A2UI, an open protocol for agents that render UI from declared component catalogs. MCP Apps became the first official extension to the Model Context Protocol, and it puts agent-rendered interfaces inside Claude, ChatGPT, and VS Code.
Agent-rendered UI is the newest surface where people meet software. Designers are not in the loop that produces it. Not authoring it, not reviewing it, in most organizations not yet aware of it.
A catalog is a design surface
In these protocols, the agent cannot render anything it wants. It composes from a catalog: a declared set of components the host is willing to draw. The catalog is the contract. Whatever it allows, the agent will eventually ship to a user.
That makes the catalog the design system of agent UI. It decides which components exist, which variants are legal, which properties are free and which are fixed. Those are design decisions, the same ones a design system team argues about for months.
Today catalogs are authored as developer JSON. There is no tooling for the people who are trained to make exactly these decisions. So the decisions get made anyway, implicitly, by whoever writes the file. The design authority did not disappear. It moved into a file format designers do not touch.
Why a second model is the wrong reviewer
The reflexive fix is to point another model at the output. Ask an AI to review the AI's interface for brand compliance. This fails for a structural reason, not a quality one.
A model's review is an opinion. Run it twice and you can get two different opinions. You cannot audit it, you cannot write it into a brand contract, and you cannot tell a stakeholder what it will say tomorrow. Stacking a probabilistic reviewer on a probabilistic generator compounds the uncertainty you were trying to remove.
And it is unnecessary, because brand compliance at render time is not a matter of taste. Whether a hex value is one of your tokens is a fact. Whether 13px sits on a 4px grid is arithmetic. Whether gray text on a blue button clears a 4.5 to 1 contrast ratio is a formula with a published spec. Taste went into choosing the tokens and the scales. Checking them needs no judgment at all, so nothing probabilistic should be doing it.
AI proposes. A deterministic engine disposes.
That sentence is the whole architecture. Use a model where the problem is genuinely fuzzy: translating a design system document into a draft catalog, naming a semantic intent, explaining a violation to a human. Use deterministic code everywhere a guarantee is claimed: same input, same verdict, every run, forever.
I did not arrive at this in a lab. I spent two decades in design and the last several years shipping AI systems inside a large regulated enterprise, where the first question about any AI output is not how good it is but whether you can stand behind it. The pattern that survives that environment is always the same one. Let the model draft. Let something checkable decide.
glph Catalog is that pattern applied to the newest design surface.
What glph Catalog does
glph Catalog is a designer authoring and governance layer over the component catalogs agents render from. The loop has three steps.
- Author the brand layer. Color tokens, a spacing grid, a type scale, radius tokens, contrast thresholds, and an allowlist of components and variants. A model can draft this layer from your existing design system. You correct it. The draft is a proposal, never a verdict.
- The agent renders. A2UI messages stream in, exactly as the protocol defines them.
- The engine checks every render. Pure deterministic code walks the tree and flags five families of violation: color not a token, spacing off grid, type off scale, radius not a token, contrast too low, plus components and variants outside the allowlist. Every violation carries an auto-fix, and the engine emits a corrected tree you can render instead.
The public demo seeds one of my favorite bugs: a button with a 13px font and 13px padding. Off scale, off grid, by one pixel. A human reviewer misses it on a good day. A model reviewer flags it sometimes. The engine flags it every run.
The same engine is exposed as an API. Here is live output, captured from the running endpoint while writing this, trimmed to one violation of the five it found:
{
"deterministic": true,
"valid": false,
"summary": {
"total": 5, "errors": 5,
"byRule": {
"color-not-token": 1, "spacing-off-grid": 1,
"type-not-in-scale": 1, "contrast-too-low": 1,
"component-not-allowed": 1
}
},
"violations": [{
"nodePath": "Card>Button",
"rule": "contrast-too-low",
"prop": "textColor",
"found": "#9CA3AF on #2563EB",
"expected": ">= 4.5:1",
"autoFix": "color.primaryText"
}]
}The catalog exports two ways: the glph format with the brand layer intact, and a standard A2UI JSON Schema catalog with the brand rules compiled into enums, so any compliant host inherits the governance for free.
What it refuses to do
The engine never calls a model. Not as a fallback, not as a tiebreaker. If a check cannot be made deterministic, it does not go in the engine.
It does not judge taste. It will not tell you a layout feels cramped or a palette feels dated. Those calls belong to designers, made once, upstream, where they become tokens and rules the engine can hold.
It does not replicate what the protocols already give away. A2UI handles schema validation and capability negotiation in the spec. Rebuilding that would be a toy. glph sits one layer up, on the question the spec leaves open: your components are valid, but are they yours.
And it is not pretending to be a venture-scale platform. It is a working proof of an argument, built to be inspected. The ecosystem it rides on is young, and the honest claim is narrow: this is what designer-owned governance of agent UI looks like, running.
Own the catalog
Every design era has a moment when the authority moves and the discipline is slow to follow. Print designers hesitated at the web. Web designers hesitated at mobile. The work went to whoever showed up.
The authority is moving again, into catalogs. Deciding what an agent may render, under which constraints, with which tokens, is design work. It is the most leveraged design work available right now, because one catalog governs every interface an agent will ever assemble from it.
If designers do not author these files, engineers will, with no malice and no system. The brand erosion will be slow, one ungoverned render at a time, and by the time it is visible it will be policy. The alternative is cheap: show up early, bring the rules, and put them somewhere a machine can enforce them.
Own the catalog. It is the design system now.
Bring your own experience
The catalog does not have to belong to the brand. Read the protocol closely: in A2UI it is the client that declares which catalogs it supports, and the client is your side of the conversation. Structurally, the design system of agent UI can live with the person, not the product.
The web already taught us the first words of this language. Dark mode and reduced motion are user-side design tokens: you declare them once, and respecting them is now table stakes. We simply never extended the vocabulary. Extend it and you get a portable experience profile: your palette, your type floor, your contrast floor, your density, your motion limits, authored once and carried everywhere you interface. Design your own UI and UX and take it with you. Bring your own experience.
The engine does not change. It changes hands. The agent proposes an interface, and this time your engine disposes. Determinism matters even more on this side, because the sharpest case is accessibility: a person who needs 16px type and 7 to 1 contrast cannot accept "usually." A preference honored probabilistically is a preference denied.
It is also personalization without surveillance. Today personalization means software watching you and guessing. BYOE means you declare and software obeys. Your experience is a file you own, not an inference you leak.
Brands and people will disagree, and the answer is more determinism, not less. Precedence is a rule like any other. The brand keeps its components, its structure, its voice. The person owns presentation where it meets their eyes and hands. Written down, checked the same way, every run.
That is the full shape of glph: design and UX for AI. Catalog is the brand side, shipped first because brands feel the pain first. Bring your own experience is the person side, same engine, pointed the other way. Everyone has a design system now. Most people will never call it that. They will only notice that every screen, on every surface, finally meets them on their terms.
Try it
The studio is at glph.ai/catalog. Edit the tokens and rules and watch the engine re-judge a live A2UI surface as you type, before and after, with the contrast math shown. Then switch on an experience profile, low vision, dyslexia-friendly or reduced motion, and watch the same surface get re-judged on your terms. The method page at glph.ai/catalog/method documents the loop and the rule families. The engine itself answers at POST glph.ai/api/check: send an A2UI stream, get the verdict, the violations, and the corrected tree. GET the same URL for a ready-to-run sample.
One note on process, because it is part of the argument. I designed this and wrote almost none of the code. Claude built it with me, to a brief, against fixtures, with every guarantee landing in deterministic TypeScript a test suite pins down. A designer directing an AI that proposes, with an engine that disposes. The tool is the thesis.
If you are working on agent UI, governance, or the protocols underneath them, I want to compare notes. Find me at michaelhiggins.ai.