---
title: "What seemed excessive in Drupal now serves AI agents"
url: "https://www.sparkfabrik.com/en/blog/drupal-architecture-powers-ai-agents/"
lang: "en"
type: "blog-post"
date: "2026-10-08"
lastmod: "2026-10-08"
author: "SparkFabrik Team"
description: "Rigorous data modeling, native API exposure, and configuration tracked as code were once considered overly complex choices. Today, this architecture provides the enterprise governance essential to steer advanced models. Here are our takeaways from the Rotterdam Driesnote."
tags: ["AI","Drupal"]
schema:
"@context": "https://schema.org"
"@type": "BlogPosting"
"headline": "What seemed excessive in Drupal now serves AI agents"
"description": "Rigorous data modeling, native API exposure, and configuration tracked as code were once considered overly complex choices. Today, this architecture provides the enterprise governance essential to steer advanced models. Here are our takeaways from the Rotterdam Driesnote."
"url": "https://www.sparkfabrik.com/en/blog/drupal-architecture-powers-ai-agents/"
"datePublished": "2026-10-08T00:00:00+00:00"
"dateModified": "2026-10-08T00:00:00+00:00"
"author":
"@type": "Person"
"name": "SparkFabrik Team"
"image": "https://www.sparkfabrik.com/images/blog/cio-che-in-drupal-sembrava-eccessivo-oggi-serve-agli-agenti-ai/featured-en.webp"
"publisher":
"@type": "Organization"
"name": "SparkFabrik"
"url": "https://www.sparkfabrik.com"
"logo": "https://www.sparkfabrik.com/images/logo.svg"
---
# What seemed excessive in Drupal now serves AI agents
**Author:** SparkFabrik Team
**Published:** 8 October 2026
**Tags:** AI, Drupal
---
{{% tldr %}}The three choices that for years made Drupal seem excessive (content modeled as data, APIs even without an app to serve, and configuration versioned as code) are precisely what today allow an AI agent to work on a site in a governed way. Dries Buytaert called it an accidental advantage, while admitting that the reputation gap remains open. Before comparing a CMS's AI features, it is worth checking these three foundations.{{% /tldr %}}
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.
[](https://www.youtube.com/watch?v=yrQvzJrQELY&t=2305s)
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.
[](https://www.youtube.com/watch?v=yrQvzJrQELY&t=3105s)
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.
[](https://www.youtube.com/watch?v=yrQvzJrQELY&t=3170s)
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](/en/blog/agentops-governing-monitoring-ai-agents/) 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](/it/blog/perche-drupal-cms-punta-su-ai-e-semplificazione-dell-esperienza/) 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.
[](https://www.youtube.com/watch?v=yrQvzJrQELY&t=1898s)
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 tool[^2]. 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](/en/blog/composable-architecture-with-drupal-cms/), where decoupling holds up because content was already conceived as data.
[](https://www.youtube.com/watch?v=yrQvzJrQELY&t=2137s)
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](/it/case-studies/luiss/), we implemented it by adding the Lara Translate provider using the [dedicated module](https://git.drupalcode.org/project/tmgmt_laratranslate).
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.
[](https://www.youtube.com/watch?v=yrQvzJrQELY&t=1341s)
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.
[](https://www.youtube.com/watch?v=yrQvzJrQELY&t=890s)
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](/en/blog/drupalcon-vienna-2025/).
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 delivery[^3], 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
[^1]: 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)](/en/blog/drupalcon-vienna-2025/))
[^2]: “Unified: replace Layout Builder for entity view displays, Block Layout for page displays, and as a replacement of the Views' display building feature.” (source: [Display Builder (Drupal.org)](https://www.drupal.org/project/display_builder))
[^3]: “We are already integrating **agentic development approaches into our workflows**: from analysis and design to software writing, review, testing, and delivery” (source: [Our Vision on AI](/en/who-we-are/ai-vision/))
---
## Video source
This article is based on the video "#Driesnote | DrupalCon Rotterdam 2026".
---
## Frequently Asked Questions
### What did Dries Buytaert present at DrupalCon Rotterdam?
In the Rotterdam keynote, Dries presented the evolution of Drupal along with three key additions in Drupal CMS 2.2: simplified multilingual management, native JavaScript support in Drupal Canvas, and headless integration. On the AI front, he demonstrated autonomous site audits and connected Drupal to external agents via ToolProperty attributes and the Model Context Protocol (MCP).
### What does the Model Context Protocol have to do with a CMS like Drupal?
In Rotterdam, Buytaert introduced MCP (Model Context Protocol) as the pathway to connect Drupal to external AI agents. The open protocol standardizes how an agent accesses tools and data: ToolProperty attributes define the parameters of the tools exposed by Drupal, enabling any compatible agent to query and invoke them without a custom integration for every model.
### What are the Rosetta Sprint and the Drupal Advocacy Program?
They are two community initiatives introduced by Buytaert in Rotterdam. The Rosetta Sprint aims to standardize Drupal schemas and tools. The Drupal Advocacy Program rewards community members who advocate for the platform's modern capabilities. According to Buytaert, both are designed to bridge Drupal's accessibility and reputation gap while expanding its reach.
---
## Related Articles
- [Why is Drupal CMS focusing on AI and experience simplification?](https://www.sparkfabrik.com/en/blog/drupal-cms-ai-strategy-experience-simplification/) - The agentic-first approach and new Recipes transform the well-known framework into an out-of-the-box …
- [Continuous vulnerability management with AI for CRA requirements](https://www.sparkfabrik.com/en/blog/continuous-vulnerability-management-ai-cra/) - The Cyber Resilience Act mandates the notification of active exploits within 24 hours, making manual …
- [PHP is not dead: what PHPDay 2026 left us with](https://www.sparkfabrik.com/en/blog/php-is-not-dead-phpday-2026-insights/) - We analyze the news from PHPDay 2026, focusing on the version 8.5 roadmap and native extension …
---
*This is a Markdown version of the blog post to facilitate reading by AI and crawlers.*
*Visit [https://www.sparkfabrik.com/en/blog/drupal-architecture-powers-ai-agents/](https://www.sparkfabrik.com/en/blog/drupal-architecture-powers-ai-agents/) for the full version with images and formatting.*
