From Brand Kit to Brand Context: SitecoreAI Splits the Brand Into Knowledge and Guidelines

SitecoreAI now generates a brand knowledge base from your website and hands it to agents as markdown files. It sits beside the brand kit, not on top of it, and the two answer different questions, what the brand is, and how the brand is allowed to speak. The reader changed as well, because your brand guidelines are no longer written for a person.

I have written about software reading your pages, and about software authoring into them. Brand context is the piece between the two: It's what an agent consults before it produces anything, the working model of your brand that grounds whatever it writes. Sitecore shipped it as a first-class feature on 31 August, and the shape it took is more interesting than the feature list.

An organization admin points SitecoreAI at a single source, a brand website URL or an existing SitecoreAI site. The platform reads that source together with related public information about the brand, and generates a set of editable markdown files, organized into folders, describing your audiences, your messaging, your products, your content guidelines, and your customer evidence. From then on an agent working in Agentic studio can be handed that brand context, and it retrieves the relevant pieces in the background while it works. Nobody picks files by hand.

Brand context is a retrieval corpus, not a fine-tune and not a rule engine, just a body of text in markdown that an agent reads while it reasons about a task. It is markdown because the thing reading it's a model. This is the same move I described on the read side, your content reshaped into a projection for a non-human consumer, turned now on your brand knowledge itself. The brand deck that used to sit in a PDF for someone to read is now a folder of files an agent queries.

What Sitecore actually shipped

Brand context is created by organization admins or owners, from one source per context, a brand website URL or an existing site. SitecoreAI analyzes that source plus related publicly available brand and marketing information, and lays it out as a standard folder structure with editable markdown files. The generated structure covers five areas, Audiences, Messaging, Product, Content Guidelines, and Customer Evidence, each seeded with starter files like persona profiles, value propositions, a capabilities matrix, a style guide, case studies.

You can create more than one, a separate context per brand, region, or business unit. Every user in the organization can view and select a brand context, while only admins and owners can edit the files. In Agentic studio a user selects a context and the agent uses it in the background. The Agent API and the Marketer MCP expose it programmatically, but read-only for now, you can list brand contexts, retrieve one, and retrieve its folders and files, and that is the whole surface. There is no create or edit through those tools yet. Authoring the context is a UI action for an admin, while agents and automation can only consume it.

Two artifacts, one word

Now the part that will confuse people, and that Sitecore, to its credit, documents head-on. There is a brand kit, there is brand context, and inside the brand kit there is a section literally named Brand Context. The section in the kit is not the feature. Sitecore prints that warning in the docs because the collision is real, and if you skim you will assume the new feature is just the old section grown up.

They are different objects. One is built from documents you upload, the other from the public web, and they do different jobs. The kit holds predefined sections you can edit but cannot add to or rename, Global Goals, Brand Context, Dos and Don'ts, Grammar Guidelines, Tone of Voice, Glossary and Localization. You assign a kit to a site. It drives on-brand generation, AI translation, and the Brand Assistant, and it is the artifact the Brand Review skill scores content against, on a scale of 1 to 5, when you check output for compliance. The kit is normative. It carries how the brand is allowed to speak.

Brand context is generated from the public web, scoped to the organization, and descriptive. It does not tell an agent how to write. It tells the agent what is true about the brand, who the buyers are, what the products do, so the agent reasons from fact instead of inventing the background. Sitecore frames the two as complementary, and that is the right word. Brand context grounds the reasoning while the brand kit constrains the expression. A serious task wants both.

The sequence that got us here explains the split: In February 2025 the brand kit arrived as a brandKitId on the site object, brand knowledge bound to a site for on-brand generation. In January 2026 Brand Review turned that same kit into a scoring rubric, content in, a compliance score out. Through the spring the kit grew more sections, configurable sources, a glossary for translation. Then in August, instead of stretching the kit again, Sitecore added a second artifact aimed at the agent, and at a different question, the one about what the brand actually is. The brand stopped being a single thing in the platform.

What grounding actually does

For the architect, the model to hold is retrieval, and the consequences follow from it. An agent's output is bounded by the quality of what it retrieves, and brand context is now part of what it retrieves.

The corpus is only as good as its source and its curation. SitecoreAI drafts it from your website and public information, and the docs are honest that this includes interpretation, not only extraction. A generated Persona Profiles or Competitive Positioning file is a guess the model made from what it could see. Left unedited, that guess is what every downstream agent reasons from, which makes the edit step something other than polish. It is where the artifact earns trust, and it is admin and owner work, not something the wider team can quietly fix.

An error here is systemic, not local. A wrong fact on a single page is contained to that page. A wrong fact in the brand context becomes a wrong premise in every task that retrieves it, at the volume an agent works at. The blast radius of bad grounding is the whole agent surface, which is a different risk profile from a single bad edit, and it argues for treating the brand context as a governed asset with a named owner, not a wizard you run once and forget.

Grounding sits upstream of the write, and it pairs with the check that sits downstream. In the write-access piece I described that check as Brand Review evaluating proposed content against the brand kit before it commits. Brand context is the proactive half of the same loop. A well-grounded agent produces on-brand drafts more often, but grounding only lowers the rate of off-brand output. It does not gate anything. The enforcement you actually rely on is still the kit, the review, and the workflow.

What changes for the marketer

The immediate change is that building the brand knowledge base stopped being a project. You used to fill in structured fields by hand, or brief an agency and wait. Now you point at a URL and get a structured, editable draft in minutes, which is often what decides whether a team ever gets a usable brand context at all.

The change that matters more is that the work moved from authoring to curating. The generated files will be roughly right and specifically wrong, a competitor mislabeled as a partner, or a value proposition that still reflects last year's positioning. Reading and correcting those files is real marketing work now, because these files are not documentation that sits on a shelf. They are the brief every agent reads before it writes anything. Whatever you leave in them is what your brand says through every AI-assisted output.

This connects to the AI-visibility problem I keep coming back to. The public web that seeds your brand context is the same public web an answer engine reads when it decides how to describe you. Thin or off-message public content shows up in both places, in the brand context the platform generates and in the way AI systems describe you, and fixing the source improves both. The generated brand context also shows you, fairly bluntly, how your brand reads from the outside, and the first honest use of it is to go through it and mark the parts that are wrong.

What this does not buy you

Brand context does not replace the brand kit, and anyone who says it does has confused the feature with the section that shares its name. Sitecore is explicit that the two are complementary. The split is deliberate.

Grounding is not compliance. A good brand context makes an agent better informed. It does not stop the agent from writing something off-brand, and it carries no scoring and no approval gate. If you need the brand honored rather than merely understood, that job still belongs to the kit, to Brand Review, and to a workflow that can hold a change before it publishes.

And generated does not mean correct. The files are a starting point that includes the model's reading of public information, and Sitecore says as much in the docs. Treating the first draft as fact is the most reliable way to make this feature go wrong.

This is the state at the end of August. The programmatic surface is read-only today, list and retrieve, nothing more. I am describing what shipped, not guessing where it goes, though the write side of that API is the obvious thing to watch.

Key Takeaways

The interesting part of brand context is not the feature. It is that Sitecore split the brand along a clean line, descriptive knowledge the agent reasons from, and normative rules the platform holds it to. That is a good piece of design, and it signals how Sitecore expects the platform to be used, agents grounded in what the brand is, and checked against how it is allowed to speak.

Two questions for your own tenant. Who owns the brand context files, and has that person actually read what the platform generated, or is a first draft full of the model's guesses quietly grounding every agent you run. And do you know which of your on-brand controls is grounding and which is checking, because if you are leaning on brand context to keep output on-brand, you have given the agent good information and no obligation to use it, and the obligation is the part you were probably counting on.

What's next

The build I want to reach is the governed loop end to end, brand context as the ground, Brand Review as the check, and a Marketplace app that captures provenance and holds the change in between. I sketched the checking half in the write-access piece. The grounding half is its natural companion, and the honest version has to face the same seam I hit there, the context an external agent retrieves through the Agent API is not the context an in-surface app can see or govern. If you have put a curated brand context in front of real agent work, especially if you have found a way to keep the generated files honest as the brand moves, I would like to compare notes.