Three products, in three unrelated ecosystems, shipped the same idea inside a month. Drupal’s Context Control Center, an agency’s page-generation tool, and a coding agent’s design workflow all concluded that the model was never the bottleneck.
The bottleneck is that your brand exists as a PDF, your editorial standards live in a senior editor’s head, and neither can be handed to software.
What the Context Control Center actually is
The ai_context module describes its job in one line: it helps "Drupal AI use your content, rules, and standards to deliver more accurate, relevant results."
Underneath that it is a content type for context. You create context items, and they carry the machinery Drupal already applies to editorial content: moderation states, scheduling, multilingual handling. Scope plugins then decide when each item applies, categorizing context by use case, language, tags and site section.
It does not arrive alone. The Drupal AI Initiative now reports spanning 32 organizations and more than 50 contributors working against a public 2026 roadmap, with Drupal AI 1.4.0 shipped and the project moving to what it calls a more predictable bi-monthly minor release cadence. Dries Buytaert’s roadmap set out the ambition a year ago. This module is one of the pieces landing against it.
Read the moderation part again, because it is the interesting one. Your brand vocabulary becomes a piece of content that somebody has to approve, that can be scheduled, and that has a revision history. The rules governing AI output enter the same workflow as the output itself.
Status matters here and deserves stating plainly. The current release is 1.0.0-beta4, published August 16, 2026, against Drupal ^10.5 or ^11.2, with a dev branch updated on August 17. The project page says: "There are currently no supported stable releases." This is real, it is moving quickly, and it is not finished.
An agency reached the same conclusion from the other end
Cheppers, a Drupal shop, is selling something structurally similar without calling it context at all.
ExperienceKit is described as "Two products working as one: a governed component library we build on your brand, and AI that turns a plain-language brief into a page assembled only from those blocks."
The constraint is the entire product. Drafts are assembled "using only your approved BrandKit blocks," and because of that a page "arrives on brand and accessible from the start." Every block is built on "your colors, your fonts, your spacing."
Notice what is not being sold. Not a better model, not a cleverer prompt, not a plugin that bolts a chat box onto an editor. What is being sold is the governed component library, with generation as the thing that becomes possible once the library exists.
The same insight arrived from a coding agent
The third instance comes from a completely different direction, which is what makes the pattern worth writing down.
Claude Code’s design workflow ships a companion skill whose entire documented purpose is to convert a repository’s React design system and upload it so that generated designs "use your real components." We covered that in what the design skill’s sync step actually does, and the conclusion there was the same: the artboards are the demo, the sync is the product.
Three teams, none of whom appear to be talking to each other, building the same prerequisite. A CMS initiative, a services agency and a developer tool all decided that the useful unit of work is a machine-readable definition of the house rules.
Most organizations do not have this asset
Here is the uncomfortable part, and it is the reason this is a project rather than a purchase.
A brand book is a PDF. It is beautifully typeset, it explains the values behind the palette, and it is useless to a machine. Editorial standards usually exist as a mixture of a style guide nobody has opened since onboarding and the accumulated judgment of whoever reviews the work. Accessibility requirements exist as a checklist that gets consulted at audit time. Regulatory constraints live with the legal team and surface as objections rather than as rules.
None of that is machine-readable, and none of it can be bought. A vendor can sell you the container. The contents are yours to write, and writing them is the part organizations consistently underestimate, because it means converting tacit judgment into explicit rules and then having the argument about which rules are actually true.
That work has a useful side effect. Teams that do it usually discover their standards contradict each other in two or three places, which was true before any AI was involved and simply never surfaced.
What a context control center has to hold
Working from what these three products treat as inputs, the categories are consistent.
Brand vocabulary. Not the palette. The words. Preferred product naming, terms you never use, the difference between how you describe a customer and how you describe a user.
Audience definitions. Who a page is for, at what level of technical fluency, with what prior knowledge assumed.
Editorial standards. Structure, register, sentence length, whether you use second person, what a good opening does. The things a copy editor applies without being asked.
Accessibility requirements. Contrast floors, heading order, alt text expectations, motion limits. These are testable, which makes them the easiest category to make machine-readable and the most obviously valuable to enforce at generation time rather than at audit.
Regulatory rules. Claims you cannot make, disclosures that must accompany certain statements, jurisdictional differences. For anyone in health, finance or anything touching the EU AI Act’s transparency duties, this is where generation gets genuinely risky without constraint.
The component library. The one thing that is not text. A page assembled from approved blocks cannot drift, which is exactly why ExperienceKit and the design sync both start there.
The governance question does not go away
One caution, because this is adjacent to something we have covered at length.
Giving an AI system your rules is not the same as giving it authority, and the two get conflated in the pitch. A context control center makes output more likely to be on brand. It does not decide who approved the page, what an agent was permitted to change, or how you reconstruct an incident afterwards. Those remain open across every platform, which is the subject of our piece on whether any CMS yet meets an agent governance standard, and of our earlier survey of what each platform lets an agent do.
There is also an ownership question worth asking early. If your machine-readable brand definition lives inside a vendor’s system, you have created a genuinely valuable asset in somebody else’s container, and the same question applies that applies to any layer you standardize on. Keep a copy in a format you control.
What to do about it
Five positions, in the order I would take them.
Write the rules before you shop for a tool. Every product in this category is a container. The contents are the work, they are portable, and they are useful even if you never generate a page. Start with the ten things a reviewer most often corrects.
Start with accessibility and regulatory rules. They are already close to explicit, they are testable, and enforcing them at generation time is worth more than enforcing them at audit.
Treat the component library as the highest-leverage item. Text rules constrain probabilistically. A page assembled only from approved blocks constrains structurally, which is a stronger guarantee and the reason two of these three products lead with it.
Do not put beta software on a client’s critical path. The Context Control Center has no supported stable release. Evaluate it now, pilot it on something low-stakes, and wait for stable before it carries a deadline.
Keep the definition in a format you own. Version it in your own repository, in plain text, and sync it into whichever tool you use. The asset is the rules. The tool is replaceable.
The Context Control Center is worth watching not because Drupal will win this, but because three groups arrived at the same prerequisite independently, and that is usually what a real category looks like early.
Frequently Asked Questions
What is the Context Control Center?
It is a Drupal module, `ai_context`, that stores the rules and standards governing AI output as managed context items. Its stated purpose is helping Drupal AI use your content, rules and standards to deliver more accurate, relevant results. Context items get Drupal’s normal editorial machinery, including moderation, scheduling and multilingual support, and scope plugins control when each item applies by use case, language, tags or site section.
Is it production ready?
No. The current release is 1.0.0-beta4 from August 16, 2026, and the project page states that there are currently no supported stable releases. It requires Drupal 10.5 or 11.2 and above. It is worth evaluating and piloting now, but putting beta software on a client deadline is a different decision.
How is this different from prompt engineering?
Scope and persistence. A prompt is written by one person for one task and disappears. A context store holds the organization’s rules once, applies them across every generation, and puts them under editorial control so changes are reviewed and versioned. The difference is closer to the difference between telling someone your preferences and writing a style guide.
What is ExperienceKit?
An offering from the Drupal agency Cheppers, described as two products working as one: a governed component library built on your brand, and AI that turns a plain-language brief into a page assembled only from those blocks. Drafts use only approved blocks, which is what makes the output on brand and accessible from the start. It approaches the same problem as a context store from the component direction rather than the rules direction.
Why do component libraries constrain better than written rules?
Because the constraint is structural rather than probabilistic. Text rules tell a model what you would prefer, and a model may or may not comply on any given generation. A page assembled only from approved components cannot contain an unapproved component, regardless of what the model decides. That is a guarantee rather than a tendency, which is why two of these three products start there.
Do I need Drupal for any of this?
No. The pattern is platform independent and is appearing in three unrelated ecosystems at once. What matters is that your brand vocabulary, audience definitions, editorial standards, accessibility floors, regulatory constraints and component library exist in a form software can read. That work is portable and stays useful whichever platform or tool you eventually adopt.
Does this solve AI governance?
No, and conflating the two is a mistake worth avoiding. Making output more likely to be on brand is a quality control. Governance is about who approved a change, what an agent was permitted to do, and whether you can reconstruct what happened. Those questions remain open across every content platform, and a context store does not answer any of them.
Where should the rules actually live?
In a format you control, versioned in your own repository, and synced into whichever tool consumes them. A machine-readable definition of your brand and standards is a genuinely valuable asset, and it takes real effort to produce. Creating it inside a single vendor’s system means the effort is not portable if you change tools, which is a bad trade for something this expensive to write.
