Drupal AI Context (CCC) — Study Notes

Submitted by sysop on Tue, 09/01/2026 - 13:28

Drupal AI Context (CCC) — Study Notes

Drupal AI Context (CCC) — Study Notes

Compiled from a tutoring session. Sandbox reference: Drupal Umami demo profile.

⚠️ Version note: Context Control Center (CCC) is an active, fast-moving Drupal AI Initiative project. As of the sources below, there are no supported stable releases — the project is in beta (Beta 3 as of 18 July 2026). Treat details here as accurate to that point in time, and re-verify against the current issue queue / release notes before relying on them in production.


1. What CCC Is (The "Why")

Definition: Context Control Center (CCC) is a native Drupal feature — not a contrib bolt-on — shipping in Drupal 11.3 as part of Drupal CMS 2.0 (formerly Starshot). At its core, it's a centralized system of AI Context config entities that store structured context: tone rules, domain knowledge, guardrails, and voice constraints, so every AI interaction on a site pulls from the same source. (Source: Drupal Odyssey, "The Context Control Center: Architecting AI in Drupal")

The problem it solves: Without CCC, each AI feature on a site (a chatbot, a product-description writer, a search assistant, etc.) needs its own separately-typed instructions. Every time a rule changes, someone has to remember to update it everywhere it was pasted.

The Networking Analogy (developed in session):

  • CCC is like a DHCP/RADIUS server: one central place holding config, with multiple "clients" (AI features) pulling from it — instead of manually configuring every device individually.
  • Extending the analogy further: DHCP isn't just handed out once — it's a lease that gets renewed. This maps directly onto CCC's two context-delivery patterns:
    • Push-based injection — context is appended to an agent's system prompt upfront (like an initial lease).
    • Pull-based retrieval — an agent can actively request context in the moment via CCC's Context Tools (like a lease renewal check-in). (Source: TheDropTimes, "Kristen Pol Explains How Drupal's Context Control Center Governs AI Context")

The three core value pillars (confirmed against documentation):

  1. No duplication — you don't retype the same instructions into each AI feature.
  2. Easier updates — change it once, centrally, instead of hunting down every place it was pasted.
  3. Better organization — context items can be organized by topic, language, or site section, linked to specific pages, and grouped so related items are used together. (Source: Drupal.org, "Context Control Center (CCC)")

2. Important Boundary: CCC vs. Claude Projects

The pattern of "shared context across some features, narrower context for others" is structurally similar between Claude.ai Projects and CCC — both are reusable, selectively-applied context systems. However: CCC is specific to Drupal's own AI features running inside a Drupal site (config entities in Drupal 11.3 / Drupal CMS 2.0). Nothing in the documentation found indicates Claude.ai Projects connects to or interoperates with a Drupal site's CCC. Conceptually parallel, not the same system, and not confirmed interoperable.


3. The Two-Step Configuration Model

Step 1 — Create the Context Item (the "config file")

This is where you author the actual instructions/knowledge.

Umami example: A context item called Recipe Tone Guide containing: "Always describe recipes in a warm, home-cook tone. Avoid technical culinary jargon. Refer to readers as 'you,' not 'the user.'"

Context items are managed as full content entities — with drafts, approvals, scheduling, version history, moderation, revisions, and multilingual support, all within a UI consistent with Drupal CMS 2.0. (Source: Drupal.org, "Context Control Center (CCC)")

Step 2 — Connect the Item to a Feature/Agent (the "lease assignment")

This is where you tell a specific AI agent to pull from that context item.

SettingWhat It DoesKey Nuance
GlobalAlways included, applied to (effectively) every agentStill subject to Context Limits (max items/token budget) — could get trimmed if budget is tight
Always IncludeIgnore other configuration and always include contextGuaranteed inclusion, but ignores other settings — can override scoping restrictions like language, so use with caution
Never IncludeIgnore other configuration and always exclude contextHard exclude
Target EntitiesInclude context associated with certain content entities (e.g., only the Recipe content type)One of several scope plugin criteria
Scope SubscriptionsConfigure agents to opt-in to the most relevant scopeThis is what ties scopes to specific agents
Context LimitsMax context items and token limitsControls cost

(Source: Drupal.org, "Context Control Center (CCC)")

Testing a connection

The documentation gives this concrete test pattern:

"if your context says 'always add the word hello when you respond,' and your prompt for the 'Content Type Agent' is 'list all the content types,' then the response should have 'hello' in it somewhere" (Source: Drupal.org, "Context Control Center (CCC)")

Testing happens via the agent debugger at /admin/config/ai/agents. AI provider setup (a prerequisite) is configured at /admin/config/ai/providers. (Source: Drupal.org, "Context Control Center (CCC)")

Umami translation: If Recipe Tone Guide is wired correctly, asking an agent to "write a description for the Umami Watercress Soup recipe" should return something warm and jargon-free, in second person.


4. Settings vs. Scopes — An Important Distinction (Worked Example)

Scenario worked through in session: A context item, Spanish Recipe Terms, that should apply only to Spanish-language Recipe pages — not English recipes, and not Spanish non-recipe pages (like "About").

Initial (incorrect) instinct: Always Include + Target Entities.

Why Always Include was wrong here: Its definition — "ignore other configuration and always include context" — means it would override any language restriction placed on top of it, causing the Spanish terminology to leak into English recipe pages too.

Correct model (confirmed via documentation):

"Context scope plugins categorize context items by criteria such as use case, language, tags, site section, or target entities, and agents subscribe to the scopes most relevant to their tasks." (Source: Drupal.org, "Context Control Center (CCC)")

This confirms language and target entities are two separate, stackable scope criteria — not one nested inside the other. So Spanish Recipe Terms would carry two scopes at once (language: Spanish + target entity: Recipe), and the agent's Scope Subscription is what ties both together at request time.

Takeaway distinction:

  • Settings (Global / Always Include / Never Include) — control whether and how forcefully a context item is included.
  • Scopes (language / target entities / site section / use case / tags) — control which content/requests the item is even relevant to in the first place.

5. Forward-Looking Note (Newer Beta Feature)

Per TheDropTimes coverage of Beta 3 (released 18 July 2026): child items can now override inherited scope, letting a broad policy carry narrower language- or entity-specific instructions. This is a newer pattern — confirm it exists in your installed version before relying on it. (Source: TheDropTimes, "Drupal AI Context Beta 3 Adds Import Sources and Per-Agent Limits")


6. Open Question (Not Yet Resolved / Needs Hands-On Verification)

The exact UI mechanics for combining two scopes (e.g., how you literally add both a language scope and a target-entities scope to one context item in the admin form) were not found in the sources gathered during this session. This is a good next step to verify hands-on in the Umami sandbox, or by checking the module's current admin UI / issue queue directly.


7. Sources Cited


8. Suggested Next Step

Build Recipe Tone Guide (Section 3, Step 1) in the Umami sandbox, connect it via Target Entities → Recipe, and test it using the agent debugger pattern from Section 3 to confirm the concepts hold up hands-on.