Why an AI cannot represent your brand
Berger+Team · Sep 25, 2026
Topic: Machine-readable website
An AI can quote your text. It cannot reproduce how you look — it does not know. And that is not the AI's fault: the brand of most businesses is written down nowhere in a form a machine can read.
What a machine sees of your brand
Your colours live in the stylesheet, as #1a1a1a among a thousand other rules. Your typeface lives in a font file with no readable name. Your logo is an image. Your brand manual is a PDF someone exported three years ago.
For a human, that is enough. For a machine it is not a vocabulary — it is pixels and formatting instructions. An AI asked to represent your business in an answer — in a card, a summary, a generated preview — has no source for the question "which green is your green, exactly?". So it guesses. Or it leaves it out.
That is the difference between being quoted and being represented. We have written about the first often. The second is open.
How widespread the problem is
On 18 September 2026 we ran a probe: 18 domains that operate a design system as a product — organisations for whom colour and type are not decoration but the business itself.
Zero out of eighteen publish their design tokens at a discoverable address.
The probe had positive controls: we first verified that our method actually finds a file that exists, and we avoided the familiar trap where a server answers something at any invented address, making every measurement worthless. Eighteen is a small sample and proves nothing about the state of the web. But the signal is clear: even the specialists do not put their design at an address.
It is not about size
The obvious objection would be: too large, too much, impractical. It does not hold.
The same tokens have long been on npm. GitHub's @primer/primitives, for instance — a package of roughly 55 megabytes, unpacked. So the data exists, and it is even published. Only it sits where developers fetch it to build an interface, at a volume nobody downloads to answer a single question.
Our own file is 6.3 kilobytes. That is the difference: not the format, the selection. An agent does not need every spacing value and every state variant — it needs the roles. Which colour is the brand colour, which is the background, which typeface carries headings.
The mistake we found in our own house
Before publishing anything, we read our own values — the way an agent would read them. The result was uncomfortable.
Our two most prominent colour roles, primary and accent, both pointed at the same light grey. Our actual brand mark, a mint, sat next to them unnamed — an internal variable that means nothing outside our stylesheet. Our house typeface pointed at a placeholder, equally meaningless off-site.
A machine reading that would have described our brand as grey. Technically correct, factually wrong. And nobody would have noticed, because the site looks right in a browser.
What we did about it
At btlabs.dev/design-tokens.json you will find our design vocabulary: thirteen colour roles across two themes, four type roles, in the format of the Design Tokens Community Group (DTCG 2025.10).
Three decisions behind it that we think transfer:
Public is whatever has a role. What we declare as design vocabulary gets published. What is internal implementation — spacing, transitions, helper variables — stays in. A machine should know the roles, not our implementation.
Values are resolved, not copied. A reference to another variable is computed the way a browser would — once per theme. That is why brand reads #87fad4 in dark and #0a7a5b in light, without anyone maintaining two values.
What cannot be resolved stays visible. It is not quietly smoothed over. A gap you can see is a gap you can close.
What this does today — and what it does not
Honestly: no search engine scores it. No ranking changes. We know of no service that fetches this file today and does anything with it.
It is a bet. It says: once assistants start not merely naming businesses but representing them — in cards, summaries, generated views — they will need a source for colour and type. Whoever has one then gets represented correctly. Whoever has none gets guessed.
We consider the bet cheap, because the stake is small: the file is generated from values that are maintained anyway. It costs no extra upkeep.
Design tokens are only one part of a bigger question: how to design a website for two readers in the first place. What that looks like in practice is described by Florian Berger in We design for people and machines.
What you can do
If you want to check how your brand looks to a machine: open your stylesheet and ask whether a stranger could tell from it which colour is your brand colour. Not which value sits where — which role it plays.
If the answer is "not really", you are in good company. Eighteen out of eighteen.
Frequently asked questions.
What are design tokens?
Design tokens are the named building blocks of a visual identity: colour roles such as background, foreground or brand colour, plus type roles such as heading and body. Instead of a colour value buried somewhere in a stylesheet, it states which ROLE that value plays — and that is exactly what a machine can read.
Does a design-token file improve rankings today?
No. No search engine scores it, and we know of no service that fetches it today. The benefit is a bet on the next step: once assistants start not merely naming businesses but representing them, they will need a source for colour and type. Whoever has one then gets represented correctly rather than guessed.
How do I tell whether my brand is machine-readable?
Open your stylesheet and ask whether a stranger could tell from it which colour is your brand colour — not which value sits where, but which role it plays. If your brand colour is called --colour-3 in the code, or sits unnamed beside two identical greys, a machine cannot find it.
