Brand Is a System

A brand used to be a book: a logo, a palette, a typeface, a tone of voice, and a few pages of do's and don'ts. Someone read it, interpreted it, and applied it by hand. A design system used to be a different book, kept by a different team, for a different audience.

I don't think of them as two books anymore. A brand is a system, and a design system is the brand in executable form. The distance between them is the distance between what a company says it is and what its product actually does on screen. Closing that distance is a product decision, not a marketing one.

It matters more now, because the people applying the brand are no longer only people.

A system is a set of decisions someone else can rely on

The most durable thing I made at Microsoft Education wasn't a screen. In 2014 I created the assignments schema, the data model underneath Microsoft Classroom. It carried forward into School Data Sync and then into Microsoft Teams Assignments, long after the interfaces on top of it changed.

That taught me what a system is: a set of decisions other people can build on without asking you first. A good schema, a good token set, and a good brand guideline all do the same job. They let the next team move fast, in a direction you'd agree with, while you're not in the room.

Immersive Reader taught the other half. It went from a concept to 46M monthly active users, and much of that reach came through the public Immersive Reader SDK: a few lines of code that let any web experience launch the reader. The experience scaled because it was packaged so other teams could adopt it, not because it was redesigned for each of them. The OneNote accessibility work, measured against Microsoft's strictest internal scorecard, made the same point from another angle: consistency is what makes quality enforceable.

Octuple: a design system built to be a chameleon

When I founded Octuple at Eightfold, the hard part wasn't the components. It was the decision to make Octuple the single source of truth for the platform, displacing a patchwork of local components and third-party widgets. That decision is why it reached 10,000+ production implementation points in under eight months.

What makes Octuple distinctive is that it's theme-agnostic by design. One ConfigProvider at the root carries the brand, so components don't have to:

• Themes, named or custom: primary and accent palettes, gradients, and a variable map that resolves to CSS custom properties.
• Typography: registered custom fonts.
• Shape and size: density and corner geometry as configuration, not forks.
• Locale and direction: right-to-left support from the same components.
• Accessibility and behavior: focus-visible handling, form defaults, and feature flags.

I designed it to be a chameleon. The same React components can wear Eightfold's brand, a customer's white label, or a brand that doesn't exist yet, without a single component being rewritten. The brand is an input, not a fork.

Brands live in other people's software too

The part of brand systems that's easy to skip is everything you don't own: the marketing site on HubSpot, the embedded form, the vendor widget, the help center, the checkout. Customers don't see an org chart. They see one company, and every seam is a brand moment.

My approach is to treat third-party surfaces as dependencies, because that's what they are:

• Where the platform runs React, use the system directly. Octuple is React, so it can be wrapped, themed, and versioned like any other dependency in the stack, with the ConfigProvider setting the brand at the boundary.
• Where it doesn't, ship the brand as tokens. CSS custom properties and exported palettes let a HubSpot template or a vendor theme inherit the same decisions without inheriting the code.
• Own the seam. Wrap vendor components behind your own component boundary, so you can swap or restyle them once instead of in fifty places.

A design system that only works inside your own repository is a style guide with extra steps.

AI-native brand: writing for agents, not only people

At Pulumi, the system's audience changed. More and more of what gets built (pages, prototypes, slides, product surfaces) starts with an agent. An agent doesn't read a brand book the way a designer does. It reads whatever context it's given.

Before AI accelerated what my peers could build, my design-system work at Pulumi was grounded in atomic design: tokens composing into atoms, atoms into molecules, molecules into patterns and pages. When the team moved to AI-native workflows, that system became the blueprint. Atomic design turned out to be the perfect conduit for agents. Its structure is explicit, hierarchical, and composable, which is exactly the shape an agent needs to learn a brand quickly and apply it without guessing.

You can see where that leads in Pulumi's brand site, brand.pulumi.com. Alongside the guide and the downloadable assets, it publishes an MCP server: context and tools that let AI agents create on a team's behalf, inside the brand. The guideline stops being a document someone interprets and becomes an interface something can call.

I work the same way day to day. I prototype in the real stack, against real components, with agents doing a lot of the typing. When an agent's output looks wrong, the fix is usually upstream: a token that wasn't expressed, a pattern that wasn't documented, a decision that lived in someone's head. Agents punish implicit design decisions, so a good system makes its decisions explicit.

This site runs the same way

This portfolio is my own test bed. It runs on an autonomous agent workflow that I steer from Slack:

• Tailored by construction. For each company or client I'm talking with, an agent builds a tailored route: a pitch, a résumé, and a cover letter. The résumé can only select and reorder facts that already exist in this site's content; it can't reword or invent them, and the build fails if it tries.
• Approval-gated. Every commit, push, and merge waits for my go-ahead in a Slack DM. Destructive git operations are blocked outright, approved or not.
• One source of truth. Every tailored page reuses the same components, tokens, and case studies, so each one is on-brand without anyone redesigning it.

It's the same lesson as Octuple, one level up. When the system carries the brand and the truth, autonomy becomes safe to hand out.

Why this is a product concern

Brand and systems work gets filed under polish. I think that's backwards.

A brand expressed as a system is what lets a product grow without fragmenting: new surfaces, new teams, new partners, new markets, and now new kinds of builders. Without it, growth turns into drift: a hundred near-matches of the same button, five tones of voice, and a product that feels assembled instead of designed.

The job is to make the right thing the easy thing, for designers, for engineers, for partners on platforms you don't control, and for the agents increasingly doing the first draft. Branding decides what the product should feel like. Systems design is how that decision survives contact with everyone who builds it.

Dylan