The Context Control Center: Architecting AI in Drupal

What the CCC Actually Is (and Why Config Entities Matter)

The Context Control Center is a centralized system of AI Context config entities that store structured context — tone rules, domain knowledge, guardrails, voice constraints — and feed them into every AI interaction site-wide. One brain. Not per-prompt instructions scattered across a dozen modules.

Think of it like this: instead of every developer on your team writing their own database abstraction, you have a service container. The CCC is the service container for AI context.

The architectural distinction that matters most here? Config entities, not content entities. That single decision carries enormous weight. Config entities are deployable via Drupal's Configuration Management system. They live in your config/sync directory. They get version-controlled, code-reviewed, and promoted through environments exactly like everything else in your codebase. Your AI's personality doesn't live in the database where a content editor might accidentally lobotomize it — it lives in your repo.

The CCC works hand-in-hand with two key features that landed in AI module 1.3.0:

AI Guardrails are output-filtering rules that constrain what the LLM can return. They're negative-space constraints — they define what the system must not produce. Think of them as an allow/deny list for AI output. If your brand guide says "never use the word 'leverage'" or "don't produce content about competitor products," Guardrails enforce that at the infrastructure level, not via hope.

Field Widget Actions let AI actions fire directly from entity form field widgets. No separate UI. No context-switching. The editor is working on a body field, and the AI action is right there, governed by the same centralized context. This is what "agentic-first" actually looks like in practice — AI embedded in the editorial workflow, not bolted alongside it.

Underneath, the CCC uses RAG (Retrieval-Augmented Generation) pipelines that pull structured context from those config entities at inference time. Every AI interaction on your site gets the same foundational context, the same voice rules, the same guardrails. Consistency isn't a goal; it's a mechanical guarantee.

I Already Built This — With Markdown and a `cache/` Directory

Months before the CCC announcement, I needed to solve the same problem for a different reason: this blog.

My Symfony-based drafting agent (An in-depth post on that is coming soon!) uses a markdown file as its voice profile. That file is the brain. It contains tone rules, banned phrases, audience definitions, structural constraints — everything the agent needs to produce output that sounds like me and not like a hallucinating intern.

The pipeline architecture, runs two passes with a hard gate between them:

Pass 1 — "Blueprints": The agent generates an outline and context notes. I review them. I approve (with or without personal edits) or reject. No draft gets produced without sign-off. This isn't a suggestion box — it's a checkpoint.

Pass 2 — "Build": The approved outline is fed back in as context alongside the voice profile, and the agent generates the full draft. I review and edit for the final output.

Intermediate artifacts — outlines, context notes, research summaries — live in the cache/ directory. That directory is the local equivalent of Drupal's RAG retrieval layer: structured context that gets pulled in at generation time to keep the agent grounded.

The parallel to Drupal's CCC is direct and structural:

The meta-narrative here is hard to miss: this very post was produced through that two-pass pipeline. The outline went through Pass 1. I signed off on the structure. Pass 2 built the draft you're reading now. It's its own proof of work.

The pattern isn't Drupal-specific. It's architectural. Drupal is now formalizing it into the CMS itself, which is the right call — but the principle holds whether you're running config entities in Drupal 11.3 or Markdown files on a CLI agent. Structured context plus a review gate equals governed AI. Everything else is vibes.

"Automatic" Is a Trap

Here's the temptation: the CCC is so well-structured, the Guardrails so robust, that you wire it up end-to-end and let AI publish without human review. Full automation. Maximum efficiency.

Don't even think about it! I can not emphasize this enough!

Fully automated AI content generation — no review gate — is a liability, not a feature. The Guardrails catch known failure modes. They can't catch the novel hallucination that's technically within your tone rules but factually wrong. They can't catch the AI confidently citing a Drupal function that doesn't exist. They can't catch the subtle drift where your "authoritative yet accessible" voice slowly becomes "patronizing and vague."

The two-pass pipeline in my blogging agent exists specifically to prevent the LLM from going straight to draft without architectural sign-off. Pass 1 output is a checkpoint — the equivalent of a code review gate in CI/CD. You wouldn't merge unreviewed code to production. Why would you publish unreviewed AI content?

The CCC's human-in-the-loop workflow exists for the same reason. The architecture assumes a human gate. If you remove it, you haven't optimized the pipeline. You've removed the load-bearing wall.

Wait, why are we doing this again? Not to remove humans from the loop. To remove friction from the loop. The structured context means the human reviewer isn't starting from scratch every time — they're reviewing output that's already constrained, already governed, already shaped by the brain file. The review is faster and more focused. But it still happens.