Give your agents the brand as data, not vibes.

Every firm that puts AI agents on output surfaces hits the same wall: the output is competent and off-brand. The email renders in almost-the-right navy. The PDF header uses a font that is close to the brand font but not it. The proposal restates the tagline from memory and gets one word wrong.

The reason is structural, not a model limitation. Brand, at most firms, lives in a PDF styleguide. A human designer reads that PDF, internalizes it, and applies it. An agent cannot do that reliably. When you prompt an agent with "match our brand," you are asking it to reconstruct exact values (hex codes, font stacks, approved phrasing) from a document that was written for human judgment, or worse, from nothing at all. The model approximates. Approximation is exactly what a brand cannot tolerate, because a brand is a set of exact values applied consistently.

The standard workaround is to restate the brand in every prompt: paste the hex codes into the system prompt, paste the tagline, remind the agent about the font. This works until it does not. The values drift between prompts, someone updates the palette and forgets three of the eleven prompts that carry the old one, and the agent surface becomes the least consistent brand surface the firm operates.

The fix is the same one engineering applied to configuration years ago: stop treating brand as prose and start treating it as data with a schema, validation, and a single source that every consumer reads at use time.

What changed

This is not a new idea in the design world. Design tokens (named, machine-readable values for color, typography, and spacing) have been standard practice in product design systems for years. The W3C Design Tokens Community Group has a draft format specification, Amazon's Style Dictionary compiles token files to platform-specific outputs, and Tokens Studio pushes tokens between Figma and code. What changed in the last year is who consumes the tokens. It used to be build pipelines and component libraries. Now it is agents generating HTML, email, and PDF output on demand, and agents need the same thing build pipelines needed: exact values served programmatically, not a styleguide to interpret.

Rarefied Earth shipped this as part of Groundwork, the firm's operating substrate product, in early July 2026. The shape of the build generalizes well beyond that product, so this piece describes the pattern in enough detail to reproduce it.

The core move is a validated brand object per tenant. Not a PDF, not a wiki page: a structured record containing the operating name, the tagline, the palette as strict #RRGGBB values keyed by role (primary, accent, neutral, and so on), the typography stack, the firm's brand statements, voice calibration notes, and the logo. The object is the single source. Everything downstream derives from it.

Two design decisions in that object carry most of the value.

First, the logo is stored as SVG text, not as a PNG upload. Vector means lossless at any scale: the same logo asset renders correctly in a 32-pixel email header and on a full-page proposal cover. Storing it as text also means it can be validated, which matters because SVG is an XML format that can carry executable content. The write path rejects any SVG containing script elements, foreignObject elements, or external hrefs, and caps the file at 256 KB. An agent that serves that logo into generated HTML is serving sanitized markup, not an attack surface.

Second, the palette is validated as strict #RRGGBB at write time. No named colors, no rgb() strings, no three-digit shorthand. One format, checked when the value enters the system, so every consumer can trust the shape without reparsing.

Deriving the CSS once, at the source

The piece of the build that removes the most prompt engineering is brandCss: the system compiles the brand object into a block of CSS custom properties (one variable per palette role, typography variables, and a small set of starter classes) at the source, and serves the compiled block alongside the raw values.

The difference this makes in practice: an agent rendering a branded email does not need the hex codes restated in its prompt, and it does not need to be trusted to transcribe them correctly. It fetches the brand, drops the served CSS block into the document head, and writes markup against the variables. The exact values live in one place. The agent's job shrinks from "reproduce the brand" to "reference the brand," and referencing is something agents do reliably.

The serving side matters as much as the schema. The brand object is exposed as a tool call (in this case through the Model Context Protocol, so any connected agent can fetch it), and the response carries instructions with the data: apply these values verbatim, and never cache them across sessions. The no-caching rule is not pedantry. It is what makes the next property work.

The rebrand test

Here is the acceptance test for whether brand is actually data in your system or just prose in a new container: change the brand, and watch how long the change takes to reach every downstream surface.

If brand values are restated in prompts, templates, and hardcoded styles, a rebrand is an archaeology project. You grep for the old hex code and hope. If brand is a single validated object that everything reads at use time, a rebrand is one write. In the verification run for this build, updating a test tenant's brand (name, tagline, palette, logo, statements) and then fetching it through the agent-facing tool returned the new values in the same minute. Every surface an agent renders after that point uses the new brand, because no surface ever stored the old one.

This is the property the never-cache instruction protects. An agent that helpfully remembers the palette from Tuesday defeats the entire design.

Who edits the brand

The last piece is ownership. If the brand object can only be edited by the vendor who built the system, the firm has traded a PDF it controlled for a database record it has to file a ticket to change. That is a worse position dressed up as a better one.

The pattern that resolves it: a client-facing edit panel. In this build, the firm's dashboard carries a brand panel with color pickers per palette role, an SVG paste field with a side-by-side preview at two sizes (so the owner sees what the logo looks like small before committing it), and editable brand statements. The panel writes through the same validation gates as the operator path. One detail worth copying even if you copy nothing else: the write is scoped to the tenant structurally, from the authenticated session, never from a tenant id in the request body. Brand is identity, and letting a request parameter say whose identity is being edited is how one client's rebrand lands on another client's letterhead.

The result is that the owner controls the values, the system enforces the format, and the agents apply whatever is current. Three parties, each doing the part they are actually good at.

What to evaluate

For a firm considering this pattern, the questions that matter:

• Where does brand live today, and how many places restate it? Count the prompts, templates, email footers, and document generators that carry a hex code or a tagline. Each one is a drift site. The count is the size of the problem.

• What validates a brand value at write time? If the answer is "a human eyeballs it," the system will accept a malformed color or a script-bearing SVG eventually. Schema validation at the write path is cheap and permanent.

• Do agents fetch brand at use time, or remember it? Any caching, whether in a prompt, a fine-tune, or an agent's session memory, breaks the rebrand property. The fetch has to be cheap enough that nobody is tempted to cache.

• Can the brand owner edit the values without the vendor? If not, the single source of truth has a single point of failure, and it is a support queue.

• Is the derived form computed at the source or by each consumer? Compiling CSS variables once, server-side, means every consumer gets identical output. Letting each agent derive its own CSS from the raw values reintroduces the approximation problem one layer up.

How Rarefied Earth thinks about this work

The firm's position on agent infrastructure is consistent across everything it ships: agents are competent renderers and unreliable rememberers, so the job of the system around them is to make the right values easier to fetch than to approximate. The brand layer is the same posture applied to identity that the firm's outcome-learning and observability work applies to operations. Structure the thing agents get wrong into data, validate it at the boundary, serve it at use time, and keep the human in control of the values themselves.

For the construction and engineering firms the practice serves, the near-term version of this is concrete: branded proposals, reports, and client-facing documents generated by agents that pull the letterhead, palette, and boilerplate from one governed source instead of from whichever template someone copied last. The same rebrand test applies. If updating your logo means hunting through template files, the brand is not data yet.

Sources and further reading

• W3C Design Tokens Community Group, draft format specification. The emerging standard for machine-readable design tokens. design-tokens.github.io/community-group
• Style Dictionary (Amazon). Token compilation to platform outputs; the precedent for deriving consumable formats from a single token source. styledictionary.com
• Tokens Studio. Design-token workflow between Figma and code. tokens.studio
• MDN: Using CSS custom properties. The mechanism brandCss compiles to. developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_custom_properties
• OWASP guidance on SVG handling / XSS prevention. Why script, foreignObject, and external references are rejected at the write path. owasp.org
• Model Context Protocol. The tool-call surface the brand object is served through in this build. modelcontextprotocol.io

Related work

The published pieces on the outcome-learning loop (/writing/agent-outcome-learning-loop/) and the ops observability loop (/writing/ops-observability-loop/) treat the operations side of the same thesis: agent systems earn trust through structure, not through better prompting. This piece is the identity-surface instance. Cross-reference, do not merge.