Is Drupal Still a CMS? Its New Role in the Agentic Stack

Drupal is evolving beyond its traditional CMS role to become a governed environment for AI agents, leveraging existing architecture for structured content, permissions, and workflows. Through projects like AI Search, Tool API, and MCP Server, Drupal can now provide context, tools, and skills to external agent harnesses, enabling semantic retrieval and permission-aware actions. This positions Drupal as a key component in the emerging agentic stack, where it manages the rules and permissions while external agents handle reasoning and execution.

For most of its history, Drupal has been easy to describe: a CMS, or for developers, a content management framework. That is still true. But in 2026, it is becoming incomplete. Through projects such as AI Search, AI Agents, Tool API, and MCP Server, Drupal can now participate in RAG pipelines, expose application capabilities as tools, and allow external AI agents to interact with a site. What makes this interesting is not that Drupal suddenly "has AI." It is that much of the architecture agents need was already there. A mature Drupal application already knows how to represent structured entities, relationships, permissions, revisions, workflows, configuration, APIs, and services. Drupal doesn't just store documents. It stores structured domain knowledge together with rules governing what can be done with it . In the emerging agentic stack, that maps surprisingly well to three concepts: context, skills, and tools . Drupal content can become context . AI Search can retrieve relevant entities through semantic search and feed them into RAG pipelines. Drupal capabilities can become tools . Tool API can expose operations such as: search content query create article data publish content entity id create taxonomy term vocabulary, name And higher-level combinations of tools, instructions, and domain rules can become something closer to skills : reusable capabilities for operating a particular Drupal application. But there is another piece: the harness . This distinction matters. An agent is more than an LLM with access to some tools. The harness is the runtime around the model: the system that decides what context to provide, which tools are available, how many steps the agent can take, how failures are handled, when human approval is required, and when execution should stop. That harness might live in an external coding agent, an automation platform, or a custom agent built with something like LangGraph. Drupal can sit underneath it: Agent Harness │ ┌──────────┼──────────┐ ↓ ↓ ↓ Context Skills Tools │ │ │ └──────────┼──────────┘ ↓ MCP ↓ Drupal ┌───────┼────────┐ ↓ ↓ ↓ Content Actions Permissions This is where Drupal's role becomes more interesting. Drupal does not need to replace the agent framework. It can become the governed environment the agent operates against . Drupal's AI Search project integrates embeddings and vector search with Search API. A Drupal site can therefore expose its structured content as semantic context: Drupal entities ↓ Search API ↓ chunking + embeddings ↓ vector database ↓ semantic retrieval ↓ agent context For organizations whose authoritative information already lives in Drupal, this removes an awkward duplication. Instead of maintaining Drupal as the CMS and building an entirely separate knowledge system for AI, Drupal itself can participate in the retrieval architecture. The other direction is action. Tool API allows Drupal operations to be represented as structured capabilities. MCP Server can then expose those capabilities to external MCP-compatible agents. An external agent could discover that a Drupal application provides tools for searching content, managing taxonomy, creating drafts, or triggering workflows. The harness decides when to use them. Drupal decides whether the operation is allowed . That separation is important. Giving an LLM unrestricted database access is easy. Giving an agent a small set of explicit, permission-aware capabilities is much safer. And this is where some of Drupal's old complexity suddenly becomes valuable. Entities, permissions, revisions, moderation, workflows, plugins, and configuration were originally designed to control what humans could do. Now the same architecture can help control what agents can do. Drupal is still a CMS. It is not suddenly a replacement for LangGraph, an agent runtime, or a general-purpose Agent SDK. A more useful description is that Drupal is becoming a possible application and governance layer in the agentic stack : Drupal entities → context AI Search → retrieval Tool API → tools Domain workflows → skills Permissions → governance MCP → interoperability External runtime → harness That distinction matters. Humans see pages, fields, forms, and workflows. Applications see APIs. LLMs see context. Agents see tools and skills. The harness sees an environment it can operate. Drupal spent more than two decades building systems for structured knowledge, permissions, workflows, and controlled operations. AI agents now need many of those same things. So perhaps the interesting question is no longer: "Is Drupal still a CMS?" It is: "Could a CMS become the governed application layer behind AI agents?" Drupal is starting to make a surprisingly strong case that it can.