This week’s design news converged on one missing layer: machine-readable intent, not just machine-readable values. Token files already publish values an agent can parse; what they rarely state is where a value belongs. Southleft’s token piece entered the field’s canonical reading list and Figma shipped a feature whose core interface is a list of what may change.
The Week in Design News: Intent, Not Just Values
Every notable item in the week of September 13 to September 19 pointed at the same gap. Tokens carry values a machine can read; they do not say where a value belongs. Autodesk University 2026 ran September 15 to 17 in Las Vegas as Autodesk’s Design and Make conference, useful context but not the story.
Three items in seven days, and they rhyme. A token article entered a curated reading list. A design tool shipped a workflow that asks a designer to declare what may change. A standards body reopened the question of how conformance gets judged. None of them announced a new format. All of them moved toward the same thing: attaching a usage rule to a value.
For the sub-questions this blog tracks — what can agents perceive, and what criteria can they use — the overlap matters more than the ordering. An agent that can parse every hex value in a token file still cannot answer the only question that matters at a decision point: is this the right token here? That question needs a rule attached to the token, not a nicer container for the token. The Autodesk University 2026 dates sit in the same window, which is context for the calendar rather than evidence for the argument.
Southleft Enters the Canonical Reading List
Southleft’s “Machine-Readable Design Tokens for AI-Ready Component Libraries”, by Kelsey Ploransky and datelined September 10, was merged into Kaelig Deloumeau-Prigent’s “State of AI in Design Systems” reading list as entry nineteen on September 18. It is the fifth Southleft work there and the first about the token layer itself.
The piece is a short argument with a long tail. Its claim, in substance: “Most token systems were built for people. Agents expose where their naming, structure, and documentation break down.” A token file can list every color and spacing value without explaining where any of them belong, and an agent working from a name like gray-2 alone has little guidance about which surfaces or components it belongs on. Read the full piece at Southleft.
On 2026-09-18 it was merged via PR #19, created at 15:32:19Z and merged at 17:55:07Z. The entry’s added_on is 2026-09-16, which moves the list’s last-updated stamp to 16 September 2026. The reading list repository now holds a first entry about the token layer itself, rather than about operating models and accountability.
The neighbours already on that list show the shape of the conversation. Vercel’s “How our agents build on-brand pages with design.md” was added 2026-09-01. Uber’s “Base MCP: Teaching AI agents to speak the Base Design System” and BILL’s “How We Made Our Design System Bilingual: One Source of Truth for Humans and AI Agents” were both added 2026-08-24. Each one describes a mechanism for handing an agent rules it could not infer from values alone.
Three Token Tiers an Agent Must Distinguish
Southleft restates three tiers, and the distinction is not academic for an agent. Primitives are values with no product meaning: color.blue.500, size.4, font.weight.600. Semantic tokens assign a value a role: color.text.primary, color.border.danger, spacing.layout.section. Component tokens carry decisions specific to a component’s states and variants: button.background.primary.hover, input.border.focus.
For an agent, the tiers are not a ranking of importance but a map of where intent lives. A primitive answers “what value?” A semantic token answers “what for?” A component token answers “which state?” An agent that reads only tier one can restyle a page and still choose the wrong token at every decision point the page contains.
Role-Based vs Appearance-Based Naming
| Role-based name | Appearance-based name | What the role name adds |
|---|---|---|
color.background.surface |
blue-500 |
The surface the fill belongs on |
color.text.subtle |
gray-2 |
The text weight and its intended use |
spacing.component.inline.md |
spacing-16 |
The context the gap sits in |
shadow.card.raised |
shadow-3 |
The elevation the shadow implies |
Appearance-based names can work as primitives — that is what primitives are for. At the point of use, a role-based name gives the chooser context, whether that chooser is a person or an agent.
Figma Ships the “Allowed to Change” Interface
Figma’s release notes for September 16 and 17 describe a feature whose core interaction is selecting which layers may become inputs. A frame pasted into Weave becomes a node, and you choose the text and image layers that may be used while the original fonts, layout, and styling stay intact.
That is the whole feature, and the interesting part is what it exposes. The 2026-09-17 note, “Create on-brand content with your Figma designs in Weave workflows”, says a frame created in Figma Design can be copied and pasted into a Weave workflow, where it becomes a node; you then select the text and image layers that may be used as workflow inputs, and changes to the original design sync into every connected asset.
Read that as an interface rather than a feature. The core UI is a list of what is allowed to change. That is the same artifact Southleft argues belongs in a token description: a stated boundary on use, authored deliberately, attached to the thing it constrains. One lives in a workflow node; the other lives in a JSON field. The shape is identical.
Weave Tools: Workspace vs Figma Design
The 2026-09-16 release, “Publish Weave tools to the Figma Community”, sets a boundary of its own. Community publishing supports any output type, including video generation and 3D renderings, but only image and vector generation Weave tools are usable in Figma Design. Capability is scoped by context, and the scoping is stated in the open. The same day’s folder release added previews of folder contents, more distinct folder colors, and duplication for folders and their contents — smaller news, same habit of making structure visible before you act on it.
WCAG 3.0 Review: Machine-Checkable Criteria Next
The W3C Web Accessibility Initiative updated the WCAG 3.0 Working Draft for September 2026 and is soliciting review questions on the conformance model. If conformance criteria become machine-checkable, agents gain a second, external source of intent for decisions about components, states, and content.
The W3C WAI news item from 2026-09-10 is thin on detail and large on signal: the conformance model is open for comment. Token descriptions and component APIs are not the only place intent can live. Standards criteria are another, and they arrive with enforcement behind them. An agent that reads a token description learns what the design system permits; an agent that reads a conformance criterion learns what the organization must do. Both are rules, and both are readable only if someone writes them down.
Token Intent Coverage: The One Computable Rule
Token Intent Coverage is a ratio: tokens carrying a non-empty description that names at least one allowed context, divided by total tokens. We register two gates — TIC at or above 0.80 for the semantic and component tiers, and every color token naming allowed surfaces plus one prohibited fill.
Southleft’s worked example shows where the usage rule goes. The token description field carries it:
{
"color.text.subtle": {
"value": "{color.gray.600}",
"type": "color",
"description": "Secondary text on color.background.surface and color.background.raised. Do not use on brand or danger fills.",
"deprecated": false
}
}The description gives an agent guidance it cannot get from the gray reference alone, and it gives a reviewer a specific rule to check. That second audience is easy to forget: a rule an agent can read is also a rule a human can audit.
Which brings us to the rule this post registers for scanners.
Token Intent Coverage (TIC) = (tokens carrying a non-empty description that names at least one allowed context) / (total tokens).
Two gates:
- TIC >= 0.80 across the semantic and component tiers combined.
- Every color token’s description names the surfaces it is allowed on and at least one prohibited fill.
An agent scoring a token file for readability reports TIC and the count of role-based versus appearance-based names. A file with high value coverage but low TIC is machine-readable but not agent-usable. That distinction is the week in one sentence: the container was never the bottleneck; the missing usage rule was.
Four other rules from the Southleft piece belong in the same review. Make descriptions available with the token data rather than in a separate document. Supply component APIs, supported variants and accessibility rules alongside the tokens. Keep Figma and code names aligned, or maintain an explicit mapping between them. Record and review overrides, because recurring exceptions reveal a missing variant. And treat published token names as an API other teams depend on.
A note on method: this is desk research of official documentation, the public repository and release notes. No hands-on testing informs the claims above — we did not run Figma, Weave, or any token tooling.