The short answer: give agents three things. Your rules as data in formats they already read (brand.json, llms.txt, design tokens), a way to ask for the rule that fits what they are doing (an MCP server), and a check that says no before something off-brand ships.
How we made this: every call below was run against Artbucket's own brand on 6 October 2026, on Artbucket Cloud and its public BrandHub listing. Outputs are trimmed, not edited. The use-check response is the example from the documentation, not a live run. Artbucket is our product.
Why a PDF brand book fails an agent
A brand book is written for a person who reads it once and remembers it. An agent reads whatever you put in its context, every time, and guesses the rest. Hand it a 60-page PDF and it has to pull "our violet is #6d4aff, but not for text" out of a layout made for print. It will often get the hex right and the "but" wrong.
What an agent needs is the same thing a developer needs: each rule as a record, with its value, a sentence on when to use it, and the files it points at.
Step 1: write each rule as a record
A rule is a key, a typed value, a usage sentence and the assets it governs. This is one of Artbucket's own, as an agent gets it:
{
"key": "logo.markWhite",
"label": "Mark in white",
"type": "text",
"value": "The mark alone in white.",
"usage": "On Violet, on Night, and on photographs dark enough to hold it.",
"assets": [{ "title": "mark-white.svg", "mime": "image/svg+xml",
"url": "https://app.artbucket.io/a/49137d0a-..." }]
}
Values are typed: a color, a font, a number with its unit, a list, or text. "Never recolor the mark" is a list item under logo.neverDo, not a sentence buried on page 14. The guideline pages people read are drawn from the same records, so the two can't drift apart.
Add contexts for the cases that differ
Most rules hold everywhere. Some don't. A rule can carry variants for a context such as dark-background or instagram-story. Ask for the rules in a context and you get one rule per key: that context's own where there is one, the default otherwise. On our brand, asking for dark-background swaps one color:
{ "key": "color.primaryInk", "context": "dark-background", "type": "color", "value": "#a592ff" }
On light grounds the same key is #5b38f0. An agent writing a dark landing page never sees the light value, so it can't pick the wrong one.
Step 2: publish the rules where agents already look
Agents and the tools built on them already read a few public formats. Serve your rules in all of them from one source.
- brand.json (the AdCP brand format from AgenticAdvertising.org): names, logos with their use, colors, fonts. Ours lives on BrandHub, and
artbucket.io/.well-known/brand.jsonpoints there:{"$schema":"https://adcontextprotocol.org/schemas/v3/brand.json", "authoritative_location":"https://hub.artbucket.io/artbucket/artbucket/brand.json"} - llms.txt: every rule as Markdown, with links to the other formats. Ours opens with the listing, the guidelines for people, brand.json, rules.json and the tokens.
- Design tokens for code: CSS, SCSS, Less, Tailwind (v4 and v3), TypeScript, shadcn, MUI, Chakra, W3C design tokens JSON and DESIGN.md, all from
/tokens?format=. - rules.json: every rule, losslessly, for anything that wants all of it.
Public brands on BrandHub can be read by any agent without a key. Private ones need a key, like everything else in your workspace.
Step 3: connect an MCP server, so agents ask instead of guess
Published files are a snapshot. An agent working on a task should ask for what fits that task. That is what the Model Context Protocol is for: the agent calls a tool, gets an answer, and the answer comes from the current release.
Artbucket's MCP server is one URL, https://app.artbucket.io/api/v1/mcp on Cloud or /api/v1/mcp on your own server. The agent signs in with OAuth, and you pick on a consent screen which workspaces it sees and what it may do:
| Access | What the agent can do |
|---|---|
| Read | Search, describe, read rules, check a use |
| Suggest | Upload and suggest; what it adds waits for a person to approve |
| Edit | Edit, delete, approve, share |
The key is bound to you: never more than you can do, and gone when your access goes. Tools the key can't run don't appear in the agent's list at all. In Claude Code, the plugin adds the server and a skill in two commands:
/plugin marketplace add pwnera/artbucket
/plugin install artbucket@artbucket
Then the agent calls brand_rules with the context it is working in, and gets back the records from Step 1.
Step 4: check before anything ships
Rules tell an agent what to make. They don't tell it whether a given file may run. A photo's license may have expired, a logo may have been replaced last week, an image may be cleared for Germany and not for the US. Ask before you use:
POST /api/v1/check
{ "asset": "...", "channel": "paid-social", "territory": "DE", "context": "dark-background" }
A refusal says why, and what to use instead (the documentation's example):
{"allowed": false,
"reasons": [{"code": "superseded", "message": "Replaced by Blender logo mark", "blocking": true}],
"suggest": [{"id": "...", "title": "Blender logo mark", "url": "https://.../a/...", "why": "Its replacement"}]}
The reasons cover approval, archiving, replacement, embargo, expiry, territory, channel, model release and the brand context. Suggestions are checked too, so an expired replacement is never offered. The same check is the check_use tool over MCP, artbucket check on the command line (it exits 1 on a refusal, so it can fail a CI job), and "Can I use this?" in the app.
Step 5: see what an agent finds about you
BrandHub's public score page looks at a domain the way an agent would: an llms.txt at the root, a /.well-known/brand.json, colors, typefaces, a logo, a voice, design tokens, and an MCP server named in the llms.txt. It scores them out of 100 and lists what is missing. Try it on your own domain at hub.artbucket.io/score.
Questions
Do agents need an account to read our brand?
Not for a public BrandHub listing: its brand.json, llms.txt, rules and tokens are open. Private brands need a key, scoped by you.
Can an agent change our guidelines?
Only with a key that may. With Suggest access, what it uploads or proposes waits for a person. Every edit is a draft until someone releases it, and portals only ever show the release.
We already have a PDF. Do we start over?
No. Start with the rules agents get wrong most: colors with their use, the logo files and when each applies, typefaces, and two or three lines on voice. That is most of what an agent needs, and the pages for people come from the same records.
Isn't llms.txt enough?
It is a good start, and it costs nothing. It can't answer "may this photo run in Germany next week", and it is only as current as the last time someone edited it. Serve it from the same source as everything else, and add the check for anything that ships.
Related: why brand rules should be data, not PDFs, and which DAM and brand platforms have an MCP server.