AI Search and Conversational Experiences on a Drupal DXP

Drupal gets typecast as "that big enterprise CMS." That framing undersells it. Drupal is a digital experience platform (DXP) with a content model strict enough to build serious AI on top of — and that structure is exactly what most "add AI to the website" projects are missing.

I've spent the last 18 months shipping production AI web experiences — grounded search, streaming chat, RAG pipelines on Google's Vertex AI — alongside two decades of CMS and content-architecture work. When I look at a Drupal DXP, I don't see a constraint. I see the cleanest backend I could ask for to put AI-powered search and conversational components in front of users. Here's how I'd build it, and where teams usually go wrong.

Why Drupal is a good substrate for AI — because it's a CMS, not in spite of it

Retrieval-augmented generation is only as good as your retrieval, and retrieval is only as good as your content structure. Most AI-on-the-website efforts fail at the foundation: they're pointed at a pile of unstructured HTML and PDFs, so the model guesses. Drupal doesn't give you mush.

• Structured content as a first-class citizen. Everything is an entity — nodes, taxonomy terms, media, users — composed of typed fields and organized into bundles. A "Program," a "Service," a "Campus" isn't a blob of markup; it's a structured record with fields you can chunk, embed, and cite precisely.
• API-first out of the box. JSON:API has shipped in Drupal core since 8.7, and the contributed GraphQL module covers the cases where you want a tailored schema. Your content is already addressable, queryable, and ready to feed an indexing job — no scraping required.
• Editorial governance built in. Workflows, Content Moderation, revisions, and multilingual all live in core. That matters more for AI than people expect: it's the difference between an assistant that answers only from published, approved content and one that leaks a draft.
• A real caching model. Cache tags and cache contexts give you surgical invalidation. When an editor saves a node, you know exactly what to bust — including the embeddings derived from it.

The architecture I'd reach for

The shape is the same one I run in production today: a decoupled (or progressively decoupled) React front end, Drupal as the source of truth, and a grounded AI layer on GCP in between.

  React / Next.js front end
  (AI search bar + chat widget as components)
        │
        ▼
  Drupal DXP  ──JSON:API──►  Indexer (Queue + Drush/cron)
  (source of truth)             │  embeds content with
        ▲                       │  Vertex AI text-embedding
        │                       ▼
   cache tags             Vector store (RAG retrieval)
   invalidate                   │
   embeddings on          ┌─────┴───────────────┐
   node save              ▼                     ▼
                   Gemini on Vertex AI    Dialogflow CX
                   (grounded synthesis)   (structured flows)

Keep Drupal as the single source of truth

The content lives in Drupal; the vector index is a derived artifact, never a second copy of the truth. I wire hook_entity_update() / hook_ENTITY_TYPE_update() (and insert/delete) to push the changed entity onto Drupal's Queue API. A worker re-embeds just that content with Vertex AI's text-embedding model and updates the index. Editors publish in Drupal the way they always have; the AI layer follows within seconds. No nightly full re-crawl, no stale answers.

The front end: React components, progressively decoupled

You rarely have to choose "all Drupal" or "all React." The pragmatic path is progressive decoupling: let Drupal render and govern the page, and mount React "islands" for the interactive pieces — the AI search experience and the chat assistant — that consume JSON:API. Teams that want a fully decoupled build can run Next.js against the same JSON:API surface and keep Layout Builder for editorial control of everything else. Either way the AI surfaces are self-contained, versioned React components with a clean contract to the backend — which is exactly how a component architecture should be organized.

The conversational layer: search and chat, both grounded

I treat this as two surfaces over the same grounded knowledge:

• AI Search — the "AI Overview" pattern. A user asks a real question; Gemini synthesizes one answer only from the retrieved Drupal content and shows the source records it used. Answers with receipts, not guesses.
• Conversational chat — multi-turn, streaming, grounded the same way, with a clean handoff to a human when the content doesn't cover the question. For structured, goal-oriented flows ("start an application," "book a tour"), Dialogflow CX / Conversational Agents handles the deterministic path, and Gemini handles the open-ended Q&A. Right tool per intent.

The parts teams get wrong

• Hallucination. If the assistant will say anything, it will eventually say something false. Ground every answer in retrieved content, cite the source, and design it to decline when the content doesn't cover the question. On a regulated or high-trust site, "I don't have that — here's how to reach a human" beats a confident wrong answer every time.
• Stale indexes. The embedding index drifts the moment editors publish. This is precisely where Drupal's entity hooks and Queue API earn their keep — re-index on change, not on a timer.
• Access control. Decoupling doesn't suspend Drupal's permission model. JSON:API respects entity access; your indexer must too, or you'll quietly surface unpublished or restricted content through the chat box.
• Cost and latency. Run the cheap, fast model where it's good enough (Gemini Flash for most synthesis), cache aggressively, and put budget gating and a kill switch in front of the LLM calls. I've shipped exactly that telemetry in production — it's not optional at scale.
• GCP governance. Use the Vertex AI enterprise path with Application Default Credentials and a least-privilege service account — no API keys floating around. When an org policy blocks a deploy, the move is a narrow, project-scoped IAM override, not disabling the safety control.

I've built this end to end

This isn't a whiteboard sketch. I built enroll.kevinchamplin.com — a customer-facing AI search + streaming chat assistant grounded on a program catalog, with cited sources, built on Gemini via Vertex AI, Vertex embeddings for RAG, React/Next.js, and Cloud Run with ADC/IAM least-privilege. The catalog there is standing in for a CMS; on a real engagement it's a JSON:API feed from Drupal. The pattern transfers directly.

When Drupal is the right call

If you're running high editorial volume, multiple languages, strict content governance, and several delivery channels, Drupal is a genuinely strong DXP — and if you're already on it, you are far closer to production-grade AI search and chat than you think. The content model you've already invested in is the hard part. The AI layer is the part I build on top of it.

If that's the problem you're solving, I'd be glad to talk through the architecture for your stack.