Anyone who has proposed Drupal for an institutional website over the years knows the exact moment when the budget approver asks to justify so much rigor. The requests for clarification almost always revolve around three points: the choice to model every piece of content into types and fields instead of composing pages, to expose it via APIs even when no app will consume it, and to version control the site configuration as if it were code. Those three choices, which seemed excessive for a “simple website,” now allow an AI agent to operate on Drupal in a governed way: it finds pre-structured content, accesses it via APIs, and acts on a configuration tracked just like any other code.
This reversal became evident during the “Driesnote” at DrupalCon Rotterdam. Dries demonstrated AI agents working on top of the platform and argued that Drupal’s existing architecture provides an accidental advantage with the arrival of AI. In the same talk, however, he acknowledged that Drupal still faces an open accessibility and reputation gap, and anyone deciding on a CMS investment needs to weigh both aspects together.
The historical critique and the current advantage actually stem from the very same decisions, viewed eleven years apart. To understand how the same architecture transforms from an overhead into an asset, we need to revisit those three choices one by one, looking at how they seemed back then and what they deliver today.
The three choices from 2015 that seemed excessive
In 2015, Drupal’s architecture required teams to pay an upfront cost that many projects did not see repaid in the short term. In our experience, three choices in particular, then perceived as excessive, are now the foundation for enterprise AI, visual page composition with governance rules, and a composable architecture that supports growth.1 We formulated this perspective after DrupalCon Vienna 2025, and the demos from the Rotterdam keynote put it to the test.
Structured content. Back then, it meant modeling content as data, with typed fields and explicit relationships instead of pages laid out in an editor, requiring more analysis before writing a single line of text. Today, that content is reusable information across different channels and machine-interpretable, because every field declares what it contains.
API-first. Back then, making content accessible through programmatic interfaces in addition to the CMS front-end seemed useful only for niche decoupled projects. Today, it is the channel through which an external system, whether an app, a workflow engine, or an agent, queries the site without going through HTML.
Rigorous configuration management. Back then, exporting, versioning, and deploying every configuration change across environments seemed like process overhead for small teams. Today, it provides full traceability of who changed what, when, and in which environment.
In our experience with Drupal projects, resistance to these choices usually centers on the analysis phase. The content model demands decisions that stakeholders would prefer to postpone, and the configuration deployment workflow is seen as bureaucracy until there is a need to understand why a permission or a content type drifted between staging and production.
The common thread across all three choices is system readability, because they all make the site explicitly describable, both in its content and its behavior. For a human editor, this explicitness mainly represented an analysis cost, whereas for an automated system operating on the site, it becomes the prerequisite for acting without having to interpret pages written as free text.
What Dries Buytaert showed in Rotterdam about AI agents in CMSs
In the Rotterdam keynote, Dries traced Drupal’s evolution before addressing AI: what can be built on top of the platform today depends on how the platform has evolved.
Buytaert showcased Drupal’s AI capabilities with a demonstration of autonomous site audits. Beyond the individual checks shown in the demo, what matters to us is the condition that makes an automated audit viable. An agent can verify a website only if it finds fields with a declared meaning, explicit relationships between content items, and a configuration that is readable and comparable against an expected state. On pages composed as free-form text, the same agent would be forced to infer the structure, leading to error margins that are difficult to govern.
The second step involves connecting with external agents. Dries showed how Drupal connects to external AI agents using ToolProperty attributes and the Model Context Protocol. MCP is an open protocol that standardizes how AI agents and models connect to external tools and data sources. The system declares which operations it makes available, the agent invokes them, and it receives structured results. In this model, the agent operates exclusively on what Drupal exposes, reading fields and calling declared capabilities.
Hence Buytaert’s thesis, according to which Drupal’s existing architecture gives it an accidental advantage with the rise of AI. The very same choices that in 2015 served content reuse, integrations, and release traceability now answer a need that did not exist back then.
The question of governance remains. An agent that proposes changes to a production system raises specific questions: who authorizes the operation, what gets logged, and how do you roll back to the previous state. In our view, version-controlled configuration management already addresses the last two, because every configuration change becomes a comparable and reversible artifact. However, it does not reveal what the agent does while it operates, nor does it establish who must approve its actions before they hit production. This is why observability and control of agents in production are required, designed as a distinct layer.
Drupal CMS 2.2 puts a simple experience on top of the same structure
If Drupal’s reputation is that of a powerful yet cumbersome platform to configure, the updates in Drupal CMS 2.2 head in the opposite direction. According to Buytaert, this release introduces simplified multilingual support, native JavaScript development in Drupal Canvas, and headless integration. This trajectory did not start in Rotterdam: Drupal CMS’s bet on AI and a simplified experience is the central theme of the project, and 2.2 extends it to the tools that teams and editors use every day.
Compared to the 2015 choices, these innovations correspond to the other two outcomes we attribute to that architecture: visually composing pages within shared guardrails and an architecture built from composable parts. Simplification does not remove structure: it moves it beneath the surface.
Drupal Canvas is the visual page building tool for Drupal CMS. According to Buytaert, version 2.2 supports native JavaScript development, bringing front-end teams closer to the same tool used by editors. For us, a visual page builder remains governable only if what the editor builds continues to be structured content and trackable configuration, meaning components with declared properties and pages that can be versioned and diffed. On the surface is a drag-and-drop experience, underneath is an explicit data model.
It remains to be seen in the field whether Canvas will handle complex projects, those with large content volumes, editorial workflows spanning multiple roles, and brand and sub-brand design systems on which user experience consistency depends. Furthermore, Canvas is not the only path for site building in Drupal: alternative initiatives exist, such as Display Builder from UI Suite, which aims to replace Layout Builder for entity view displays, Block Layout for page displays, and Views display building with a single tool2. The right tool must be chosen on a project-by-project basis, tailored to the content, processes, and design system it will need to support.
Among the new features in 2.2, headless integration is the one that stems most directly from the 2015 choices: the API-first approach becomes an out-of-the-box product capability rather than a custom architecture built by hand, paving the way for setups where Drupal serves content to diverse front-ends and services. This is the territory we explored when discussing composable architecture with Drupal CMS, where decoupling holds up because content was already conceived as data.
Regarding simplified multilingual support, the third update highlighted by Dries, version 2.2 builds on one of Drupal’s historical strengths. Core handles languages, content translation, interface translation, and configuration translation, and around this core foundation there are several ways to organize translation workflows. One is the TMGMT module (Translation Management Tool), which manages translation jobs and sends them to external services via providers. In our case study on Luiss University, we implemented it by adding the Lara Translate provider using the dedicated module.
Managing multiple languages benefits from content modeled as data, because translation is applied field by field and relationships between language versions remain explicit. Conversely, a site that treats languages as cloned pages multiplies alignment work with every update, making it opaque to any agent tasked with checking consistency.
Is an unperceived advantage still an advantage?
Today it carries little weight. The strongest counterargument to the accidental advantage thesis, in its most compelling form, is that an architectural advantage not perceived by the market does not factor into purchasing decisions. If an IT Director still associates Drupal with the notion of being “too much,” demos of agents remain an insider talking point.
Compounding this is a second, equally valid concern. Tying a CMS choice to AI is risky if AI turns out to be a bubble, because an architectural investment justified solely by agents would lose its purpose along with the hype.
The first answer comes from within the community itself: from the stage of its flagship event, Dries acknowledged that Drupal still faces an open accessibility and reputation gap. The fact that the platform’s founder openly states this carries significant weight.
Two responses were announced. Dries introduced the Rosetta Sprint, which aims to standardize Drupal schemas and tools, and the Drupal Advocacy Program, which recognizes community members who advocate for the platform’s modern capabilities: both initiatives are designed to address the gap and expand Drupal’s reach. In our view, standardizing schemas also reinforces the exact trait agents require: predictable structure from one site to another. An agent configured to operate on one installation will find the exact same conventions on the next.
Regarding the bubble concerns, the relevant perspective comes from outside Rotterdam. At DrupalCon Vienna 2025 (October 14 to 17), Buytaert argued that AI is here to stay even if the financial bubble bursts, describing Drupal as one of the best-positioned open-source CMSs to leverage it: a stance we captured in our report from Vienna.
As an AI-native company, we agree, with an added nuance drawn from our day-to-day work. At SparkFabrik, we integrate agentic development approaches into our workflows, from analysis and design to review, testing, and delivery3, and for that very reason, we know that an agent is only as good as the structure it operates on. Those three choices already served content reuse, integrations, and traceability long before agents came along. That is why they retain their value even if AI expectations deflate.
The gap remains open until these two initiatives show tangible results, and as of today, there are none to report. The architectural advantage is real, but on its own, it is not enough to shift the perception of those evaluating a CMS from outside the community.
Three checks before comparing AI features
For anyone choosing or upgrading a CMS with AI agents in mind, the decision criterion shifts from the list of built-in AI features to the quality of the structure on which an agent will operate. Before comparing product brochures, three conditions should be checked: whether content is modeled as data, with explicit fields and relationships; whether it is accessible via APIs, independent of the front-end; and whether configuration changes are versioned and traceable across environments.
If any of these three conditions is missing, the agent will operate on content it can neither reliably read nor govern, and any AI feature built on top inherits that flaw. This test applies to any platform, Drupal included. Apply it to your current content model and release workflow before watching a commercial demo. In our experience, these three questions are what separate projects ready for agents from those that need to rebuild their foundations first.
Notes and sources
Note e fonti
Video source
This article is based on the video “#Driesnote | DrupalCon Rotterdam 2026”.
According to SparkFabrik, Drupal’s 2015 architectural choices (structured content, API-first, rigorous configuration management), which seemed excessive at the time, are today the necessary foundation for enterprise-grade AI, governed visual page building, and scalable composable architecture. This assessment originates from DrupalCon Vienna 2025 (October 14 to 17, 2025), not from DrupalCon Rotterdam. (source: DrupalCon Vienna 2025: what we learned (and what changes for you)) ↩︎
alternative initiatives exist, such as Display Builder from UI Suite: “Unified: replace Layout Builder for entity view displays, Block Layout for page displays, and as a replacement of the Views’ display building feature.” (source: https://www.drupal.org/project/display_builder) ↩︎
We share this stance as an AI-native company. At SparkFabrik, AI is part of all processes and the way we develop…: “We are already integrating agentic development approaches into our workflows: from analysis and design to software writing, review, testing, and delivery”: Our vision on AI (source: </it/chi-siamo/ai-vision/>) ↩︎
