Your agent is not ignoring your design — it never got the rules

Set up any design handoff properly — a Figma Dev Mode connection, a structured Canva export, a Claude Design bundle — and you will find the same residue of dissatisfaction on the other side. The screen is right. The next screen is nearly right. The one after that has a heading size you have never used and an accent colour on an element that should not have one.

The instinct is to blame the model, and it is the wrong diagnosis. Every one of those routes transmits geometry: elements, positions, sizes, colours, sometimes component structure. None of them transmits reasoning. The agent received what the design contains and nothing at all about why — which values were deliberate, which were incidental, and what the rules are for a screen nobody has drawn.

Concretely, there are two questions the agent has to answer to produce on-system work, and no export format answers either.

• Was this value intentional?: A colour bound to a variable and a colour someone typed in under deadline arrive identically. So do a heading in your type scale and a heading someone nudged two pixels. The agent reproduces both faithfully, which means it reproduces your mistakes with the same confidence as your system.
• What applies to screens that do not exist?: This is the larger one. A settings page, an empty state, a permissions error, a billing failure — nobody designs these first, and everybody needs them. There is no selection to send and no file to export. The agent has to infer, and it infers from the average of everything it has ever seen rather than from anything of yours.

The missing half is smaller than people expect. It is not a design system in the engineering sense — not components, not tokens, not tested and versioned code. It is the layer before that: the decisions an agent needs while it is building, written where it can read them.

• Colour roles, not hex codes: A hex code records what was used once. A role governs what happens next: this is the single accent, it appears on primary actions and active states and nothing else; this is the surface; this is the destructive state. Roles generalise to screens that do not exist yet, which is the entire point.
• Type ownership and the sizes that exist: Which face owns headings, which owns body, and the actual scale. State what is not in the scale too — the invented 19px heading between two real ones is one of the most common drift symptoms, and naming the boundary prevents it.
• Spacing and motion as numbers: The values, not adjectives. "Generous" and "snappy" are resolved differently by two sessions of the same model an hour apart. A spacing scale and a transition duration are among the cheapest things to write down and the most visible when they are wrong.
• A named audience: Microcopy register follows entirely from who is reading. "Technical buyers evaluating an on-premise tool" and "first-time users" produce different words for the same button. Name them once and the tone stops sliding between screens.
• A never list: Negative constraints do more work than everything above them combined. No gradients on surfaces. Never centre body copy. No emoji in product UI. Each one closes off an entire family of plausible-looking wrong answers before the agent goes anywhere near it — and unlike positive instructions, they cannot be satisfied halfway.

Writing the rules down is the easy half. Where they live decides whether they keep working.

• In the prompt: Works once. Costs you the retyping every session, and the wording changes slightly each time — which is exactly how two screens end up on two systems. Taste that has to be re-typed every prompt is not a system, it is a habit with a failure rate.
• In a repository markdown file: A genuine improvement and free to try. It survives the session and travels with the code. It stops scaling at the second repository and breaks at the third client, because now there are four copies of the rules and they diverge quietly — nobody notices until a screen comes out on last quarter's palette.
• In a source the agent queries: One place the rules live, read on demand over the same MCP transport the agent already uses for everything else. Update it once and every connected project sees the change. The agent pulls only what the request needs rather than carrying the whole thing all session.

The third option is worth a note on cost, because the objection is usually context budget. A serialised set of design decisions is small — well under a couple of thousand tokens for most products, and only the relevant parts get pulled for a given request. That is a rounding error next to the base64-inlined HTML export some workflows are sending instead.

An agent follows a rules layer the way it follows any other instruction: usually, not religiously. You will still correct things. What changes is the baseline — the starting point moves from the average of the model's training data to something recognisably yours, and corrections become adjustments rather than rebuilds.

It also does not replace the design handoff. You still need the export or the connection or the bundle, because the rules describe every screen and the handoff describes this one. Two inputs, doing different jobs. The mechanics of the first are in how to export a UI design to a coding agent.

Ask your agent, in a fresh session with no design attached, to build a settings page for your product. Do not describe the styling. Then compare it to a real screen from your product.

Check four things: the accent colour and what it landed on, the heading size, the spacing rhythm, and the tone of the microcopy. Every one of those that matches came from a rule the agent could read. Every one that does not is a decision that currently lives only in your head, or in a design file the agent was never going to open.