A concept on the horizon, explored

A token holds a single decision. A component is a whole assembly. The interesting work lives in the gap between them, and people have worked that gap for years under different names. What it never had was one shared definition that every tool could build from.

That gap used to be harmless. “The heading” might live in your CSS, your Figma file, and iOS, drifting slightly out of sync, and a designer just smoothed it over by eye. But it’s often an agent reading your files now, and an agent doesn’t smooth anything over. It builds exactly what it finds and guesses the rest. The drift didn’t get worse. It just stopped being free.

Jake Albaugh from Figma gave that gap a name: hypertokens. It belongs to a bigger argument he was making, that AI speeds up execution but not clarity, and that your intent has to stay human-authored for any of this to be worth it. Hypertokens are one piece of that: a way to hand a machine your intent without it guessing.

To be clear up front, this is not a shipped feature or an official Figma announcement. It is a concept Jake and his team at Figma are exploring openly, still on the horizon. He coined the term during his talk at Config 2026.

What follows is how it’s meant to work, what it would change for designers, how far off it still is, and a few of my own thoughts, like is this not just a composite token and do we actually have a single source of truth like this.

Start with what a token is

A design token is one named decision.

color.text.primary = #1A1A1A
space.200          = 8px
radius.sm          = 4px

One name translates to one value. The point is not the value, it is the name, because color.text.primary survives a rebrand; #1A1A1A does not. Tokens are how a design system says what it means instead of what it is.

That works beautifully for single decisions. It falls apart the moment decisions travel in packs.

The problem: Many decisions travel in packs, and every tool keeps its own copy

Look at a heading, it is never “one decision” but rather it is font family, size, weight, line height, and letter spacing, all at once, every time.

font-family: Inter;
font-size: 32px;
font-weight: 600;
line-height: 1.2;
letter-spacing: -0.01em;

If you write code, you are probably already objecting that we have always bundled this, and you would be right. A CSS class, an SCSS mixin, a Tailwind @apply, a Figma text style: each of these is just a way for code or Figma to save a bundle of properties under one name and reuse it. Bundling is not the new thing, because every toolchain already has its own version of it.

The real problem is what happens across tools. Pipelines like Style Dictionary already translate one source into many platforms, but they do that for single values rather than for bundled styles. So the same heading bundle still tends to live by hand in several places at once: the .heading-lg class in your CSS, the “Heading / Large” style in Figma, and the version again in iOS or Android. Those copies drift apart over time. Someone nudges the line height in CSS and nobody touches Figma, and a bare class name tells a machine almost nothing, since an AI agent that sees .heading-lg has to go and dig through the stylesheet to work out what is actually inside it.

One decision ends up as several hand-made copies with no shared source, and that is the gap.

Hypertokens: one named bundle, upstream of every tool

A hypertoken is a named bundle of style properties, defined once, that every tool’s copy is built from. It has the same shape as the bundles you already know, like a text style or a class, but it lives one level above them as structured data, with the values kept as clearly labelled fields rather than baked into a line of code.

The promise is that a build step, an automated tool that translates your single source into every format you need, would generate the CSS class, the Figma text style, and the Swift struct for iOS from that one definition. Think of it as export rather than copy-paste. Change the source and every platform updates, so there are no longer four hand-made copies drifting apart. And because it is labelled data rather than a class name, an agent can read the parts directly instead of reverse-engineering a stylesheet.

Typography is only the familiar example. Jake’s real move is to apply the same wrapping to everything that comes in packs, including spacing groups, surfaces built from background and border and radius and shadow, transforms, and, more aspirationally, motion. Anywhere a cluster of decisions repeats, you name the cluster once and then reuse the name.

One distinction is worth holding onto, because it blurs easily. A hypertoken is still a token, and it simply carries several properties instead of one, which does not make it a smaller component. A component is a different kind of thing altogether, since it holds structure, states, behaviour and accessibility, none of which a style bundle can carry. The cleanest way to picture it is that components are assembled from hypertokens the way a recipe combines ingredients. A token and a hypertoken are the same idea at two sizes, a named style decision, while a raw value is the unnamed stuff underneath, and the component is what you cook with all of it.

The payoff: good names mean less code, not more

This is where naming stops being tidy and starts mattering, because the thing reading your file now is an AI.

Say you have done the work and set up tokens. Good news: the AI gets color.text.primary, not a raw hex. That is exactly why tokens are worth it. But it still gets everything one property at a time. A heading arrives as five separate token references, a card as four, and nothing tells the AI “these five are the Heading” or “this is the Card.” So it receives a long, correct, but ungrouped list, and has to guess how the pieces fit and rebuild the structure from scratch. Jake put it perfectly: you asked for a cheese sandwich and got handed an encyclopedia on bread. By the time you read it, nobody is making a sandwich.

A hypertoken is the short version. Instead of fifteen lines of raw values, the AI gets two words, “Surface.brand,” and knows exactly what you mean. It reads less, guesses less, and reuses what you already have. The surprising result Jake’s team at Figma reported (note: these are Figma’s own numbers, limited testing mainly into code connect, nobody claimed otherwise): less total code and lower AI usage for a better outcome. Precision up front is cheaper than cleanup later.

So a named bundle is not housekeeping. It is the instruction set the machine builds from.

Isn’t this just composite tokens?

This was not part of the talk, but something that is important to look at, I believe. Is this not just a composite token? Largely, yes, and it is worth being straight about that, because the value survives the honesty.

The open industry standard for design tokens (the W3C / DTCG spec) already has composite tokens: tokens whose value is a small structured object holding several sub-values. The spec ships a fixed set of them: typography, shadow, border, gradient, transition, strokeStyle. A typography token bundling family + size + weight + line height already is a composite token. Jake says so himself during his talk: the pattern has been around forever.

It is also worth knowing that composite tokens are the messy corner of the spec. Tooling support is patchy, since Style Dictionary and Tokens Studio and the rest each handle them differently, and a lot of tools quietly flatten them back into single values. That is not a footnote. It is a good half of why a fresh and opinionated compile pipeline is interesting at all.

So what is actually fresh about hypertokens?

• Scope. Composite tokens are a short, fixed menu someone else chose for you. Hypertokens generalise the idea to any recurring fragment your own system has, like the exact radius, border, surface and shadow you keep calling a card. No committee to ask, no spec revision to wait for.
• Compilation, the real shift. One strict source of truth that compiles deterministically, meaning the same input always produces the same output. In the talk this wasn’t just asserted, Jake showed the pipeline running. He authored the schema himself in JSON: a DTCG-based file for the tokens, a separate file for the hypertoken structures, and “recipes” that combine those fragments into components. From that one source he compiled out a lot: text styles bound to aliased variables with code syntax attached, the component library and the icon library, Code Connect created and published in the same pass, a base CSS layer, and a base Svelte presentation layer that wasn’t just buttons but a date picker, a table and charts. One definition in, a working multi-format system out, all kept in sync. That’s a whole build pipeline, not a fancier token format.
• The part that interests me as a designer is the return trip, writing back into Figma. Also, on the design side he showed it briefly: you pick a style fragment and see every other component built from the same one, which he called an index for your design thinking, plus you can bind several properties to variables in a few clicks instead of one at a time. We only got an early peek and I’m still not sure of the details, but that visual map of how decisions repeat is exactly what I’d want, because a designer’s head thinks in visuals, not JSON.
• A handle. “Hypertoken” is a usable word for “semantic, reusable, cross-property style fragment.” A bad spec name, a very good slide name. Underneath, it’s a composite token with the fixed menu removed, and the genuinely interesting bit is the single source of truth that compiles to everything, built so a machine can read it without guessing.

There are no hypertokens…yet

You cannot press a “hypertoken” button in Figma today; it is an exploration Jake and his team are running at Figma, not a shipped feature. While the slides and testing he showed look very promising for now, in Figma, you get your usual text styles, effect styles and variables. That is the whole toolbox, June 2026, while writing this. There is no way to define one named surface.card that carries fill + border + radius + shadow and apply it as a single unit right now. The cross-property fragment, the actual hypertoken, is exactly the thing the tool does not have. That missing piece is the exploration.

So this is a concept to design towards rather than a feature to adopt, and the teams that will feel it first are the ones already running a token pipeline and a real component library rather than the solo designer shipping on their own.

What I can actually do as a designer now

Nobody knows if or when this ships. But the signals are strong: no real design-system update in Figma for a while, hires and focus tilted toward design systems and agentic work, and the groundwork already landing with Code Connect, slots, and code layers. I would be surprised not to see the update we badly need soon. Still, a bet is not a plan.

So I fall back on what I tell anyone preparing for an agentic setup. The whole thing is being built in real time. Ignore the glossy LinkedIn demos, because the real thing is messy and unfinished, even though it is moving fast. Design systems sat at the enterprise level for years, and this shift is pulling them down to every team, including very small ones. The encouraging part is that getting ready needs nothing new from you, only the same old design-system basics that suddenly matter for everyone. In practice, preparing for possible hypertokens means committing to a clear architecture you should have wanted anyway:

• Use styles and variables everywhere, and never leave a loose value in a file.
• Name variables by meaning, with primitives feeding a semantic layer. If you only do one thing, make it the semantic layer.
• Align your Figma variables and styles with the real codebase alongside your dev team, so that even where the handoff is still manual, you will be ready the moment the wiring catches up.
• Try MCP for yourself. Setting up a simple agentic workflow and connecting Figma to Claude just to tinker is far easier than it sounds, and it shows you exactly how an agent reads your file. It may not be what you use in production, but it makes you far better at talking to development, and this kind of knowledge compounds and is genuinely fun. I have a tutorial here.
• Claim your seat. This is happening now and it is dev-dominated, so ask your team to show you how they build agents and where things break or fail to line up. Designers have a great deal to offer in this transition, both inside and outside Figma, and that contribution is badly underrated.

There is a ceiling here that is worth seeing before you hit it. A hypertoken is static style and nothing more. Hover, focus, error, behaviour, and accessibility do not live in a token. They live in the component. Tokens get the look right, and they say nothing about how the thing behaves, which still needs a human.

The elephant in the room: Who gets to author??

The whole idea rests on one phrase: single source of truth. One definition, everything compiled downstream from it.

Agentic workflows pull the other way. The same agents now write into Figma, into code, and can edit the schema itself. The more places allowed to author, the less singular the source becomes: the design file, the code, and the schema all start behaving like the original, drifting, with an agent confidently merging them on a guess. A single source of truth only holds if exactly one thing authors and everything else obeys, so an agentic setup makes that discipline harder, not easier. My line: intent stays human-authored and canonical. Agents compile it outward; they do not get to quietly become the source. The moment they do, “source of truth” is just a diagram.

The one line to keep

A token names a decision. A hypertoken names a decision you keep making. The reason that suddenly matters is that something other than a human is now reading your file, building exactly what it finds, and inventing the rest. Name more, guess less.

Full credit to Jake Albaugh from Figma, the concept and the cheese sandwich are his. Original talk: Figma deep dive: Agentic workflows and the MCP | Config 2026

About the author

Christine Vallaure is a UI designer, speaker, founder of the learning platform moonlearning.io and author of theSolo, a book about independent product building. She teaches UI design, Figma, and product building with agentic AI to people who want to understand what is actually going on under the hood. Online courses, team training, conference talks.

Currently she is focusing on course on agentic AI for designers. Sign to the newsletter if you want to know more.

Constitutionally incapable of writing a short article.

What are hypertokens? The layer between tokens and components, rebuilt for agents was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.