In April 2025, there was no Top Tier badge in the plan. There was a conviction that Drupal needed coordinated investment in AI. Today, Dropsolid's recognition makes that choice visible.

What Top Tier really means

Dropsolid is now listed as a Top Tier Drupal Certified Partner. I am genuinely proud of that. Not simply because we have reached the highest level in the Drupal Certified Partner Program, but because of what this recognition measures.

We chose to help build Drupal's future. Today, that choice became visible.

Author: Will Huggins

Imagine asking an AI assistant:

"Show me waterproof jackets under £150, in size M, available for delivery tomorrow".

Today, the assistant might search the web, read several retail websites and summarise what it finds. But what if, instead of reading pages, the agent could ask retailers directly which products matched those requirements?

With that information, you could fast-track your shopping journey and ask:

"Add [my chosen product] to my basket"

The important change here isn't the chatbot; it’s what sits behind it. A traditional website can tell an AI agent what products it has and provide the details. Tomorrow’s website will give the agent a controlled way to buy it.

That is the shift from publishing pages to publishing capabilities. It fundamentally changes what we expect a CMS to do.

Ever since the early days of the internet, content management systems have had a fairly straightforward job: someone creates a piece of content, the CMS publishes it as a page, a person finds that page, and then reads it and decides what to do next.

Over time, CMS capabilities developed around improved findability of content and the experience humans have when they land on a page. AI agents are now changing that equation, introducing a different type of interaction that moves beyond pages altogether, in search of capabilities that solve a problem rather than pages to read.

A page tells you what an organisation can do. A capability lets you do it

Take that same retailer from the jacket example. Its website contains thousands of pages describing products, categories, delivery and returns information, promotions, and offers. That information is useful to both human and AI visitors. But the retailer doesn't only have information, it offers services too: searching products according to particular requirements, comparing specifications, checking availability, calculating delivery, adding products to a basket, and buying them.

The focus is on wrapping those capabilities in an interface that optimises the customer’s experience and drives greater conversion. Those ‘wrappers’ are navigation menus, search boxes, filters, buttons and checkout flows that guide someone towards that conversion target.

Think of an AI agent less like another customer and more like a personal shopper acting on their behalf. Or, perhaps, interacting directly with the shop's warehouse rather than the shop staff.

The visiting customer may care about the photography, the brand story, the layout, and the overall shopping experience. And whilst these elements remain vital in building trust with a potential customer, the personal shopper has a different job. They need to understand what the customer wants, quickly identify suitable products, check availability, compare options and, if instructed, complete the purchase.

They don't need to navigate the website the same way the customer does. In fact, forcing them through the same menus, filters and checkout steps may simply create unnecessary friction. The AI agent needs reliable, structured ways and clearly defined methods to discover what the retailer offers and what actions it can perform.

AI agents need to know not just what the retailer sells, but how to search, compare, check and buy on the customer's behalf, potentially across numerous websites at once. The retailer that makes the personal shopper's job frictionless is the one more likely to win the sale.

The webpage isn't disappearing

None of this means websites are about to become obsolete. People will continue to visit websites, and great digital experiences will still require accessible interfaces, thoughtful design, persuasive content, and strong brand experiences. A retailer still needs customers to trust its products!

But the webpage will increasingly become one interface to an organisation's digital information and services, rather than the only interface.

Drupal has been moving in this direction for a long time. The same structured content managed in Drupal can already be used across websites, applications, search experiences, feeds and APIs. Drupal is now leading the way in how AI agents can interact with websites to complete transactions.

A new definition of publishing

For a marketing team, publishing has traditionally meant putting something in front of an audience: a campaign, a landing page, or a new product

With the rise of the agentic web, publishing is developing another dimension, one that needs AI systems to understand what you offer, who it's for, whether and where it's available, what it costs, and what actions can be taken, and by whom.

That makes structured content much more than a CMS implementation requirement. It must become part of your brand architecture. The idea of ‘capabilities’ takes that idea one step further.

You don't need to start exposing every organisational process to AI agents right away. Start by asking different questions about your digital estate. Think beyond "do we have a page explaining this product or service?" and ask "what is the underlying action or outcome we want customers to complete, and could an authorised agent safely perform it?"

This is where Drupal AI gets really interesting!

Drupal already knows more than what appears on the page

Drupal has always been good at structured content. A product doesn't have to be defined simply through a large page of text called "product page."

For the personal shopper to do its job well, it needs more than a page to read. Drupal can understand that a product has a:

• Title
• Description
• Categories and tags
• Specification/attributes
• Variants of colour and size
• Different availabilities of those variants
• Price and promotion information
• Rules regarding delivery and returns

Those pieces of information can be connected to other things Drupal understands, such as related products or customer reviews.

The customer sees the finished page, but underneath that page is a structured content model that provides an AI agent with context, meaning and additional information not directly available to a human reader on the "product page."

Go back to the waterproof jacket. If an agent asks for products under £150, structured data gives it a much more dependable answer than inferring prices from paragraphs of product copy. Ask for size M, and Drupal knows which fields represent product type, features and size. Ask which jackets are available for next-day delivery, and Drupal can use live availability and delivery information rather than relying on an AI model to guess from a page's wording.

The same structured content that makes a product page useful to a human is what lets a personal shopper act on it. The Drupal AI roadmap builds on that relationship between Drupal's content model, context, governance, and trustworthy AI experiences.

But structured information is only half of the story. Drupal is now developing ways to describe actions just as clearly.

A quick guide to the alphabet soup

AI has already given us enough acronyms to fill a data center, but three are particularly relevant to the future of content management systems: API, MCP, and ARD.

API: letting systems talk to each other

An API, or Application Programming Interface, is a controlled way for one system to request information or perform an action.

In the context of agentic AI acting on a Drupal website, think of it like a service counter. Instead of navigating through the shop yourself, you make a specific request:

"Show me all products under £50 that are currently in stock."

The API defines what can be requested and how the answer comes back.

APIs aren't new. They already connect websites to apps, CRMs, commerce systems, search platforms, and countless other services.

MCP: helping AI use available tools

MCP, or Model Context Protocol, is an open standard that lets AI models safely connect to external tools, data and services.

Put simply, while an API can expose a capability, MCP gives an AI agent a consistent way to use it.

Drupal's MCP Server project builds on Tool API, making Drupal tools available to compatible AI systems. It also supports authentication, allowing individual tools to require appropriate authorisation rather than simply opening everything to an external agent.

ARD: helping an agent discover where capabilities exist

There is another problem: an AI agent can only use a capability if it knows it exists.

Agentic Resource Discovery, or ARD, is an emerging idea exploring how agents might discover services that can fulfil a particular need.

Instead of already knowing which website to visit, an agent could potentially ask a broader question:

"Who can help me find a product matching these requirements?"

Discovery and execution are different problems. One helps an agent find the right door, whereas the other helps it interact with what is behind the door.

The standards are still evolving, and nobody needs to redesign their digital strategy around a particular acronym today. The important thing is the direction of travel.

From structured content to structured capabilities

One important building block in Drupal's emerging agentic AI architecture is Tool API. It gives Drupal a consistent, reusable way to describe not only the information it holds but also the things it can do, with clearly defined inputs and outputs that Drupal AI Agents, MCP, and other automation systems can all use.

A tool might effectively say I can search products and describe what information it needs (e.g., product type, size, colour, price range and delivery requirements) and what it will return (e.g., a list of matching products).

Another might say I can check stock availability for a particular product and size, or I can add a selected product to the customer’s basket.

AI agents can reuse tools and expose them to other AI systems through technologies such as MCP. Tool API is currently available as a beta project, so this is active, evolving work rather than a finished endpoint for the vision.

The big idea is that Drupal can increasingly describe not just what it knows, but what it can do.

That is a fundamentally new Drupal capability being built on top of Drupal's existing publishing capabilities.

Drupal's Inside AI and Outside AI meet here

This is also where the Drupal AI Initiative's distinction between Inside AI and Outside AI becomes useful.

Inside AI focuses on AI working within Drupal to help you create, manage, and optimise your website. Outside AI focuses on external agents acting on Drupal.

Outside AI enables an external agent to connect to Drupal, inspect it, change it, verify it, migrate into it, or launch it. That makes the publishing-capabilities idea more than a thought experiment.

Drupal's Outside AI work is actively exploring the infrastructure needed to make Drupal a reliable and governable action surface for external AI agents: who the agent is and where it came from, reliable execution in the background, guardrails, limits on what each tool can touch, visibility into what happened, and predictable contracts between agents and Drupal.

In other words, the question isn't simply "can an AI agent make Drupal do something?" but "can we let an AI agent do something useful while Drupal still controls what is permitted, records what happened and protects everything the agent should not be able to touch?"

Publishing a capability doesn't mean handing over the keys

Imagine an AI agent interacting with a retailer. An anonymous agent might be allowed to search the product catalogue, add a selected product to that shopper’s basket, or check the status of their order.

None of those agents should suddenly gain permission to view another customer’s orders, change product prices or publish a new promotion.

Drupal has spent decades developing data access and functional controls, based on roles, permissions and workflows for human users. Those same principles become increasingly valuable when the user is an AI agent, and it’s one of the reasons Drupal AI's work on guardrails matters.

Guardrails were introduced into Drupal AI and expanded in the 1.4 release so safety and policy checks can be applied more broadly to incoming and outgoing AI interactions, including support for streaming responses. The Context Control Center (CCC) is another piece of this work, helping Drupal AI draw on the right content, rules and standards to deliver more accurate results.

In simple terms, Drupal can put rules between AI and the organisation.

As agents become more capable, that may be just as important as the capability itself.

So…what is actually new?

APIs aren't new. Drupal permissions aren't new and structured content certainly isn't new.

What’s new is how those established strengths are being assembled for an agentic web.

• Tool API gives Drupal a more consistent way to describe reusable actions. 
• MCP Server provides an emerging route for external AI systems to access approved Drupal tools.
• Outside AI is explicitly working on the identity, permissions, reliability, tool controls and governance needed for external agents to act on Drupal safely.
• Drupal AI Guardrails provide mechanisms for applying policy and safety controls around AI interactions.
• Context Control Center (CCC) gives Drupal AI the right context to deliver more accurate results.

A CMS that knows things, does things and governs both

For digital leaders, perhaps the simplest way to understand the direction is in four layers.

1. Drupal knows things: it manages structured content, relationships and context.
2. Drupal can do things: APIs and tools expose defined actions.
3. Drupal decides what is allowed: permissions, authentication, workflow and AI guardrails establish boundaries.
4. Drupal can work with agents: Outside AI, Tool API and MCP are developing the mechanisms through which approved AI systems can interact with those capabilities.

This is a very different picture of a CMS from the system many people still imagine when they hear the term. It is not simply the place where somebody logs in to edit the homepage. It becomes a critical control layer between an organisation's information, services and the growing number of digital interfaces through which people interact with them.

From publishing information to enabling outcomes

The first generation of content management systems helped organisations put information on the web. The next generation helped them structure it, personalise it, distribute it across channels and connect it to increasingly sophisticated digital experiences.

AI agents now offer a shortcut to the ultimate outcomes, which may mean they use the website on the customer's behalf. That doesn't make the CMS less important… it makes the CMS much more important because you now need a way to tell the AI agents what your organisation knows, what it can do, who is allowed to do it, and what happens when they do.

Yesterday's CMS published pages. Tomorrow's CMS publishes capabilities.

Drupal is designed to govern both.

Author: Will Huggins

Imagine asking an AI assistant:

"Show me waterproof jackets under £150, in size M, available for delivery tomorrow".

Today, the assistant might search the web, read several retail websites and summarise what it finds. But what if, instead of reading pages, the agent could ask retailers directly which products matched those requirements?

With that information, you could fast-track your shopping journey and ask:

"Add [my chosen product] to my basket"

The important change here isn't the chatbot; it’s what sits behind it. A traditional website can tell an AI agent what products it has and provide the details. Tomorrow’s website will give the agent a controlled way to buy it.

That is the shift from publishing pages to publishing capabilities. It fundamentally changes what we expect a CMS to do.

Ever since the early days of the internet, content management systems have had a fairly straightforward job: someone creates a piece of content, the CMS publishes it as a page, a person finds that page, and then reads it and decides what to do next.

Over time, CMS capabilities developed around improved findability of content and the experience humans have when they land on a page. AI agents are now changing that equation, introducing a different type of interaction that moves beyond pages altogether, in search of capabilities that solve a problem rather than pages to read.

A page tells you what an organisation can do. A capability lets you do it

Take that same retailer from the jacket example. Its website contains thousands of pages describing products, categories, delivery and returns information, promotions, and offers. That information is useful to both human and AI visitors. But the retailer doesn't only have information, it offers services too: searching products according to particular requirements, comparing specifications, checking availability, calculating delivery, adding products to a basket, and buying them.

The focus is on wrapping those capabilities in an interface that optimises the customer’s experience and drives greater conversion. Those ‘wrappers’ are navigation menus, search boxes, filters, buttons and checkout flows that guide someone towards that conversion target.

Think of an AI agent less like another customer and more like a personal shopper acting on their behalf. Or, perhaps, interacting directly with the shop's warehouse rather than the shop staff.

The visiting customer may care about the photography, the brand story, the layout, and the overall shopping experience. And whilst these elements remain vital in building trust with a potential customer, the personal shopper has a different job. They need to understand what the customer wants, quickly identify suitable products, check availability, compare options and, if instructed, complete the purchase.

They don't need to navigate the website the same way the customer does. In fact, forcing them through the same menus, filters and checkout steps may simply create unnecessary friction. The AI agent needs reliable, structured ways and clearly defined methods to discover what the retailer offers and what actions it can perform.

AI agents need to know not just what the retailer sells, but how to search, compare, check and buy on the customer's behalf, potentially across numerous websites at once. The retailer that makes the personal shopper's job frictionless is the one more likely to win the sale.

The webpage isn't disappearing

None of this means websites are about to become obsolete. People will continue to visit websites, and great digital experiences will still require accessible interfaces, thoughtful design, persuasive content, and strong brand experiences. A retailer still needs customers to trust its products!

But the webpage will increasingly become one interface to an organisation's digital information and services, rather than the only interface.

Drupal has been moving in this direction for a long time. The same structured content managed in Drupal can already be used across websites, applications, search experiences, feeds and APIs. Drupal is now leading the way in how AI agents can interact with websites to complete transactions.

A new definition of publishing

For a marketing team, publishing has traditionally meant putting something in front of an audience: a campaign, a landing page, or a new product

With the rise of the agentic web, publishing is developing another dimension, one that needs AI systems to understand what you offer, who it's for, whether and where it's available, what it costs, and what actions can be taken, and by whom.

That makes structured content much more than a CMS implementation requirement. It must become part of your brand architecture. The idea of ‘capabilities’ takes that idea one step further.

You don't need to start exposing every organisational process to AI agents right away. Start by asking different questions about your digital estate. Think beyond "do we have a page explaining this product or service?" and ask "what is the underlying action or outcome we want customers to complete, and could an authorised agent safely perform it?"

This is where Drupal AI gets really interesting!

Drupal already knows more than what appears on the page

Drupal has always been good at structured content. A product doesn't have to be defined simply through a large page of text called "product page."

For the personal shopper to do its job well, it needs more than a page to read. Drupal can understand that a product has a:

• Title
• Description
• Categories and tags
• Specification/attributes
• Variants of colour and size
• Different availabilities of those variants
• Price and promotion information
• Rules regarding delivery and returns

Those pieces of information can be connected to other things Drupal understands, such as related products or customer reviews.

The customer sees the finished page, but underneath that page is a structured content model that provides an AI agent with context, meaning and additional information not directly available to a human reader on the "product page."

Go back to the waterproof jacket. If an agent asks for products under £150, structured data gives it a much more dependable answer than inferring prices from paragraphs of product copy. Ask for size M, and Drupal knows which fields represent product type, features and size. Ask which jackets are available for next-day delivery, and Drupal can use live availability and delivery information rather than relying on an AI model to guess from a page's wording.

The same structured content that makes a product page useful to a human is what lets a personal shopper act on it. The Drupal AI roadmap builds on that relationship between Drupal's content model, context, governance, and trustworthy AI experiences.

But structured information is only half of the story. Drupal is now developing ways to describe actions just as clearly.

A quick guide to the alphabet soup

AI has already given us enough acronyms to fill a data center, but three are particularly relevant to the future of content management systems: API, MCP, and ARD.

API: letting systems talk to each other

An API, or Application Programming Interface, is a controlled way for one system to request information or perform an action.

In the context of agentic AI acting on a Drupal website, think of it like a service counter. Instead of navigating through the shop yourself, you make a specific request:

"Show me all products under £50 that are currently in stock."

The API defines what can be requested and how the answer comes back.

APIs aren't new. They already connect websites to apps, CRMs, commerce systems, search platforms, and countless other services.

MCP: helping AI use available tools

MCP, or Model Context Protocol, is an open standard that lets AI models safely connect to external tools, data and services.

Put simply, while an API can expose a capability, MCP gives an AI agent a consistent way to use it.

Drupal's MCP Server project builds on Tool API, making Drupal tools available to compatible AI systems. It also supports authentication, allowing individual tools to require appropriate authorisation rather than simply opening everything to an external agent.

ARD: helping an agent discover where capabilities exist

There is another problem: an AI agent can only use a capability if it knows it exists.

Agentic Resource Discovery, or ARD, is an emerging idea exploring how agents might discover services that can fulfil a particular need.

Instead of already knowing which website to visit, an agent could potentially ask a broader question:

"Who can help me find a product matching these requirements?"

Discovery and execution are different problems. One helps an agent find the right door, whereas the other helps it interact with what is behind the door.

The standards are still evolving, and nobody needs to redesign their digital strategy around a particular acronym today. The important thing is the direction of travel.

From structured content to structured capabilities

One important building block in Drupal's emerging agentic AI architecture is Tool API. It gives Drupal a consistent, reusable way to describe not only the information it holds but also the things it can do, with clearly defined inputs and outputs that Drupal AI Agents, MCP, and other automation systems can all use.

A tool might effectively say I can search products and describe what information it needs (e.g., product type, size, colour, price range and delivery requirements) and what it will return (e.g., a list of matching products).

Another might say I can check stock availability for a particular product and size, or I can add a selected product to the customer’s basket.

AI agents can reuse tools and expose them to other AI systems through technologies such as MCP. Tool API is currently available as a beta project, so this is active, evolving work rather than a finished endpoint for the vision.

The big idea is that Drupal can increasingly describe not just what it knows, but what it can do.

That is a fundamentally new Drupal capability being built on top of Drupal's existing publishing capabilities.

Drupal's Inside AI and Outside AI meet here

This is also where the Drupal AI Initiative's distinction between Inside AI and Outside AI becomes useful.

Inside AI focuses on AI working within Drupal to help you create, manage, and optimise your website. Outside AI focuses on external agents acting on Drupal.

Outside AI enables an external agent to connect to Drupal, inspect it, change it, verify it, migrate into it, or launch it. That makes the publishing-capabilities idea more than a thought experiment.

Drupal's Outside AI work is actively exploring the infrastructure needed to make Drupal a reliable and governable action surface for external AI agents: who the agent is and where it came from, reliable execution in the background, guardrails, limits on what each tool can touch, visibility into what happened, and predictable contracts between agents and Drupal.

In other words, the question isn't simply "can an AI agent make Drupal do something?" but "can we let an AI agent do something useful while Drupal still controls what is permitted, records what happened and protects everything the agent should not be able to touch?"

Publishing a capability doesn't mean handing over the keys

Imagine an AI agent interacting with a retailer. An anonymous agent might be allowed to search the product catalogue, add a selected product to that shopper’s basket, or check the status of their order.

None of those agents should suddenly gain permission to view another customer’s orders, change product prices or publish a new promotion.

Drupal has spent decades developing data access and functional controls, based on roles, permissions and workflows for human users. Those same principles become increasingly valuable when the user is an AI agent, and it’s one of the reasons Drupal AI's work on guardrails matters.

Guardrails were introduced into Drupal AI and expanded in the 1.4 release so safety and policy checks can be applied more broadly to incoming and outgoing AI interactions, including support for streaming responses. The Context Control Center (CCC) is another piece of this work, helping Drupal AI draw on the right content, rules and standards to deliver more accurate results.

In simple terms, Drupal can put rules between AI and the organisation.

As agents become more capable, that may be just as important as the capability itself.

So…what is actually new?

APIs aren't new. Drupal permissions aren't new and structured content certainly isn't new.

What’s new is how those established strengths are being assembled for an agentic web.

• Tool API gives Drupal a more consistent way to describe reusable actions. 
• MCP Server provides an emerging route for external AI systems to access approved Drupal tools.
• Outside AI is explicitly working on the identity, permissions, reliability, tool controls and governance needed for external agents to act on Drupal safely.
• Drupal AI Guardrails provide mechanisms for applying policy and safety controls around AI interactions.
• Context Control Center (CCC) gives Drupal AI the right context to deliver more accurate results.

A CMS that knows things, does things and governs both

For digital leaders, perhaps the simplest way to understand the direction is in four layers.

1. Drupal knows things: it manages structured content, relationships and context.
2. Drupal can do things: APIs and tools expose defined actions.
3. Drupal decides what is allowed: permissions, authentication, workflow and AI guardrails establish boundaries.
4. Drupal can work with agents: Outside AI, Tool API and MCP are developing the mechanisms through which approved AI systems can interact with those capabilities.

This is a very different picture of a CMS from the system many people still imagine when they hear the term. It is not simply the place where somebody logs in to edit the homepage. It becomes a critical control layer between an organisation's information, services and the growing number of digital interfaces through which people interact with them.

From publishing information to enabling outcomes

The first generation of content management systems helped organisations put information on the web. The next generation helped them structure it, personalise it, distribute it across channels and connect it to increasingly sophisticated digital experiences.

AI agents now offer a shortcut to the ultimate outcomes, which may mean they use the website on the customer's behalf. That doesn't make the CMS less important… it makes the CMS much more important because you now need a way to tell the AI agents what your organisation knows, what it can do, who is allowed to do it, and what happens when they do.

Yesterday's CMS published pages. Tomorrow's CMS publishes capabilities.

Drupal is designed to govern both.

Author: Martin Anderson-Clutz. Originally posted on The Acquia Blog.

Two GovCon keynotes came at disruption from opposite ends. Read them together and you get a map of the moment Drupal is in.

Earlier this month, I spent some time at Drupal GovCon, and a striking element was how well the two keynotes fit together. They were pitched under the same banner — "Building Through Disruption" — but they came at it from opposite ends. Mike Madison talked about how disruption can be something you do, on purpose, to make your team better. Kerry Greer reminded us that disruption is also something that happens to people, and that holding a team together through it is real work that rarely shows up on a ticket. Put those two talks side by side and you get something close to a complete picture: the courage to lead change, and the care to make sure nobody gets left behind while you do it.

I want to walk through both, because I think the Drupal community needs both right now.

Mike Madison: disruption is a verb

Mike (a former Acquian, now Senior Director of Global Web at Zscaler) has spent much of his career being paid, in his words, to "professionally disrupt organizations." His whole framing was a permission slip. When we talk about disruption in business we tend to reach for the giants: Netflix, Airbnb, Uber. And that framing is paralyzing, because none of us is going to reinvent a multibillion-dollar industry over lunch. So Mike flipped it. Think small. Disruption, boiled down, is just "replacing an old way of doing something," and every person in the room already has the standing to do that on their own team.

Every person in this room has the ability to go and disrupt your team or your organization in a meaningful way — and you can do that without pissing everybody on your team off, if you do it right.

His recipe was almost aggressively simple. Four steps: have an idea, figure out how you will change it, convince somebody it is a good idea, and then (the hard part) actually go do the thing. He was honest that the last step is where most of us fail. Ideas are cheap; we all have the brilliant one at breakfast that is gone by bedtime. Doing the work is what separates change from complaint.

A few of his points stuck with me. One was where to find your ideas: "channel your inner hate." The stuff that drives you nuts at work, the things that keep you up at night: that is the gold mine, because you already care enough to push. Another was a caution from science-fiction writer Isaac Asimov: it is easy to predict the car, but hard to predict the traffic jam. Even a great change has unintended consequences, and that is fine, as long as you are watching for the traffic jams.

The part most relevant to us as a technology community was his argument against standing still. He put up the most popular programming languages from 2005, when he started, with PHP sitting proudly near the top — and then watched it slide down the list decade by decade, ceding ground the whole time. His point was not that PHP is doomed; it was that the teams with the most experience are too often the ones least willing to change, and that "what goes too long unchanged destroys itself," as Ursula K. Le Guin put it. The antidote is deliberate: budget time for continuous improvement, kaizen, the way you would budget for meetings or security work. Do not wait for permission to get better.

And crucially, he was clear that driving change is a social act, not a heroic one. The story he told to prove it was about being an intern at a national lab, convinced they were using the wrong tool for the job, and knowing that the intern standing alone in front of a room of senior engineers was going to lose. So he spent a year finding allies — people with the tenure and technical credibility he did not have yet — and when the real decision came, it was not him making the pitch. It was a room full of respected voices backing the idea. That lab runs on Drupal today. His takeaway: right idea, wrong timing or wrong messenger, and nothing happens. Change is something you build with other people or not at all.

Kerry Greer: the invisible work

Kerry has been in the Drupal community for around two decades — a lineage that runs back to the early federal adopters — and she is now an account director at Forum One. Where Mike talked about disruption you choose, Kerry talked about the disruption that arrived uninvited. Over the past couple of years, the ground shifted for a lot of people who build for government: a new administration, workforce reductions, changing contracts and priorities, and AI landing on top of all of it at once. For many of her colleagues and friends, that was not theoretical. People lost jobs. Teams reshaped overnight.

Her question was different from Mike's. Not "how do I change things?" but "how do I keep creating when everything around me keeps changing?" And her answer was that the thing that carries a team through disruption is not another tool, methodology, or roadmap. It is what she called the invisible work, or the human architecture — the layer that never gets a Jira ticket.

When disruption hits, you don't have time to build the relationship. You only have time to trust what's already built.

She named five load-bearing principles, and they resonated because she illustrated them with two real projects from the past year, one that went well and one that very much did not. The difference between them, she argued, was not talent. Both teams were made of capable people doing their best in an uncertain moment. The difference was the human architecture that had — or had not — been built before the pressure hit.

Build trust before you need it, because when disruption lands you do not have time to build the relationship; you only get to spend the trust you already have. Create clarity when you cannot create certainty — when a meeting stops making sense, be the person who says so out loud, whether or not that is your job. Do not let the org chart define the team; on her successful project, the person bringing the most clarity was the most junior UX designer on it. Share what you know instead of gatekeeping, because a community that hoards knowledge does not survive disruption. And remember what you are here for: purpose is the thing that does not move when people, roadmaps, and org charts do.

She grounded all of it in who the work is actually for — the single parent trying to renew a license at the DMV with sick kids in the back seat, the family that needs to know there is a bear in their Yellowstone campground. Government does not get to stop building. When someone asked her about AI displacing the human connection, her answer was steady: AI is another tool, like Google or Word or Excel before it, and it will change some jobs — but humans have to stay in the loop, "especially in government," because the public still needs accurate information from something they can trust.

Why this is the conversation the Drupal community needs

Together these two talks are more useful than either alone. Mike hands us the agency to lead change; Kerry reminds us that leading change without tending to people is how projects quietly fall apart. And this is exactly the moment the Drupal community is in. Every team I talk to is being asked to meet familiar challenges — and some new ones — with fewer resources and, in some cases, unfamiliar tools. That is Kerry's disruption and Mike's opportunity at the same time.

Here is the optimistic part, and I do not think it is wishful. On the technical level, Drupal is unusually ready for this moment. Many of the decisions this community made years ago — treating structured content, configuration, permissions, and workflow as first-class, exportable things rather than logic buried in code — turn out to be exactly what makes a system legible to AI agents. We have been doing the unglamorous governance work for a decade, and it is about to pay off.

We are also finding new ways to embrace change as a project, not just as individuals — which is really Mike's "do the thing" and Kerry's structured collaboration operating at community scale. The Drupal AI Initiative is the clearest example. Rather than letting work this important languish or fall victim to bikeshedding, it is structured as a funded initiative with dedicated contributors, and it keeps adapting its own shape to match what the market actually needs. That recently meant splitting into two complementary tracks. Inside AI is building what partners literally ranked as their priorities — AI search first, then content review, translation, and chat-driven editing — all working together on one real, multilingual site rather than a scatter of demos. Outside AI is tackling agent experience: making Drupal "legible, callable, safe, and verifiable" for the agents that will increasingly build on our behalf, so that our decades-old advantage in governance-as-data is something agents can actually reach and trust. Both are aiming to prove the path — not just claim it — at DrupalCon Rotterdam, including at the AI Dev Summit and Enterprise AI Summit.

Notice how neatly that maps to what Mike and Kerry each described. The initiative is a room full of people choosing to disrupt an old way of doing things and then doing the hard, unglamorous work of shipping it. And it is doing so through exactly the human architecture Kerry championed: shared knowledge instead of gatekeeping, clarity of purpose, and a structure that lets contributors lead regardless of where they sit on any org chart.

So here is where their insights brought me, and it is the note I want to end on. Disruption is not something happening to the Drupal community. It is something we are equipped to lead — technically, because of choices we made years ago, and culturally, because we know how to build with each other. Mike is right that we are all more capable of driving meaningful change than we think we are. Kerry is right that the most important thing we build is not software; it is the trust and the people that make the software possible. Hold both, and this is a moment to be excited about. We get to help write what comes next, and we get to make sure that as it changes, nobody gets left behind.

The Drupal Business Survey investigates the trends in the digital market, in particular from service providers involved with the open source Drupal CMS and enterprise platform. Digital agencies from all over the world participate in the yearly survey and the business insights on market share and growth opportunities gained are shared with those who’ve submitted responses. 

Begun many years ago by Drupal Business Network with Janne Kalliola, Michel Van Velde, and Imre Gmelig Meijling, the survey is now administered by the Drupal Association to promote global reach and protect the confidentiality of the information. Moving forward, the Drupal Association will handle the analysis and reporting of the anonymised data from the survey. We're grateful to Janne, Michel, and Imre for their many years of work in shaping and running the survey.

Drupal’s open source ecosystem is supported by a strong community of tens of thousands professionals worldwide, working together on the popular digital experience platform. Because Drupal is open source, anyone can work with Drupal or make changes to it. An important part of this community are the agencies that provide Drupal services to end users and drive Drupal’s market. The Drupal Business Survey seeks the input from these agencies so that meaningful data for business owners and decision makers can be built into their business strategies. 

The Drupal Business Survey has been a valuable guide for digital service providers, even to those working with other technologies than Drupal.

Take the survey here!

About the Business Survey

The Drupal Business Survey supports Drupal businesses worldwide and is organised by the Drupal Association. The survey was founded by Imre Gmelig Meijling (React Online), Janne Kalliola (Exove) and Michel van Velde (Craftmore), and we're grateful for their years of work in building it into what it is today.

Drupal is the open source Digital Experience Platform used by many organisations worldwide including Nestlé, Lufthansa and World Wildlife Fund (WWF).

Participate and share your insights

Drupal experts are invited to share their Drupal business insights through the Business Survey anonymously and come to DrupalCon Europe to review the results together.

You can take the Drupal Business Survey 2026 anonymously here. The survey closes on 7 September.

This post is adapted from the DA Insider, the Drupal Association's monthly newsletter. Subscribe here to get it in your inbox each month.

Straight from Ryan's desk

To the Drupal community,

As northern hemisphere summer winds down, DrupalCon Rotterdam is rapidly approaching — and if you haven't booked yet, today is your last chance at Regular pricing. Late Rate kicks in at midnight CEST, so this is my friendly nudge to save yourself €270 and register now.

Rotterdam isn't the only Con on the horizon. DrupalCon Orlando Early Bird registration opens 14 September, and paid Early Bird tickets come with a limited-edition DrupalCon elePHPant — once they're gone, they're gone.

Elsewhere in this edition: the 2026 Drupal Business Survey is open until 7 September (your answers shape where we focus next), the engineering teamhas completed the migration of Drupal's security issue tracking to GitLab, and we're delighted to welcome Janna Malikova to the Drupal Association Board.

As always, thanks for being part of it. See you in Rotterdam!

Ryan Witcombe, Director, Product Marketing

The 2026 Drupal Business Survey Is Open

Your input shapes an anonymized report that helps the whole community. You'll see how your pipelines, win rates, and revenues compare to global peer data, share what's actually working, and directly influence where the Drupal Association focuses next.

Take the survey by 7 September 2026 at 23:59 UTC. Responses are strictly confidential and fully anonymized. Everyone who completes the survey receives the full report by email.

DrupalCon Rotterdam is almost here

Join Drupal experts and community members to discover what’s next for Drupal and the open web, exchange ideas, and build connections across the ecosystem in Rotterdam from 28 September to 1 October.

The regular rate is now closed, but registration for DrupalCon Rotterdam 2026 is still open. Register here.

All You Need To Know About DrupalCon Orlando

Early Bird Registration Opens September 14

The Early Bird registration for DrupalCon Orlando 2027 opens Monday, 14 September 2026 at 8:00 am EST, with tickets available for $650. And Early Bird comes with a special perk. Paid Early Bird DrupalCon tickets include a limited-edition DrupalCon PHP elePHPant named Drupy (Elephpas hypertextus drupalensis primus in Latin), available exclusively during the Early Bird registration period. 

Free tickets do not include an elePHPant, but you'll have the option to purchase one during registration while supplies are available. 

Summits & Training

Kick off DrupalCon Orlando on Monday, 22 March 2027 with a full day of deeper learning and industry-specific discussions, all available as add-ons to your registration.

Summits (Add-on $350)

Choose from six summits tailored to your interests: AI · Government · Higher Education · Nonprofit · Healthcare · Community.

Two summits with special pricing: the Community Summit is free for all DrupalCon registrants, and the Nonprofit Summit is free for Nonprofit ticket holders.

Full-Day Training (Add-on $550)

One focused training on offer: AI Inside Drupal: From Smart Editorial Workflows to Canvas Agents That Build Pages, presented by DrupalEasy.

Community Party + The First-Ever DrupalCon Talent Show

Save the Tuesday night, 23 March 2027, for the DrupalCon Community Party, featuring something brand new for Orlando: the first-ever DrupalCon Talent Show! 

It's FREE, and opting in helps us plan for everyone who wants to join us Tuesday night.

More details are coming soon.

Call for Speakers Is Still Open

There's still time to help shape the DrupalCon Orlando 2027 program! We're accepting speaker submissions through 20 October 2026. 

Submit your DrupalCon Orlando session.

Where In The World Is Bytes?

Bytes the Gator is making his way around the Drupal community and you can join the fun for a chance to win a free registration to DrupalCon Orlando 2027. Can't attend a Drupal event or find Bytes? Another alligator works too, preferably not a live one! 

Meet Bytes and learn how to enter the mascot contest.

The Engineering Team Has Been Busy

This month the team completed the migration of Drupal's security issue tracking to git.drupalcode.org, making the volunteer Security Team faster and easier to grow.

The broader issue migration now covers 90,000+ issues across 7,200+ projects. Release packages were re-signed for 3,200+ projects through Rugged, our new package signing pipeline.

localize.drupal.org and jobs.drupal.org have moved to modern cloud infrastructure, and the Drupal 11 upgrade of the new Drupal.org platform is underway.

Next up: porting community events to new.drupal.org so we can retire groups.drupal.org.

The Drupal Association At-Large Board Election Winner Is Announced

We are excited to announce the winner of 2026 Community At-Large Board Elections. We would like to congratulate and welcome our newest board member, Janna Malikova, for winning the community-elected seat.

We are grateful to Alejandro Moreno for their service and dedication to Drupal and the community, and to all the candidates who applied this year. Read the full announcement here.

This roundup is adapted from the DA Insider, the Drupal Association's monthly newsletter. Want it in your inbox? Subscribe to email communications and browse previous editions.

The Drupal Association is excited to announce the winner of 2026 Community At-Large Board Elections.

We extend a sincere thank you to Alejandro Moreno for his service and dedication, not only to Drupal, but to the Drupal community. Your time spent on the board made such a difference to the future of the Drupal project, and we thank you all for participating with grace, thoughtfulness, and insightful contributions.

We would like to congratulate and welcome our newest board member, Janna Malikova, for winning the community-elected seat during our 2026 At-Large Board Elections.

We cannot wait to see all the amazing things Janna will accomplish while on the Drupal Association Board.

Detailed Voting Results

There were 8 candidates in this year’s At-Large board member election. 307 voters cast their ballots out of a pool of 1274 eligible voters. Eligible voters are active Drupal Association members, known as Ripple Makers, whose membership must have been active at least 24 hours before voting opened.

Under Approval Voting, each eligible voter can give a vote to one or more candidates. 

The final total of votes were as follows:

On behalf of all the staff and board of the Drupal Association, a heartfelt Drupal Thanks to all of you who stood for the elections this year. It truly is a big commitment to contribution, the Drupal Association, and the community, and we are so grateful for all of your voices. Thank you for your willingness to serve, and we hope you’ll consider participating again in 2027!

Author: Will Huggins

For most of the web’s history, we have designed digital experiences around a simple assumption: a person will visit our website. That person might arrive through a search engine, follow a campaign link, scan a QR code, or maybe even type the URL into their browser.

AI is changing that... dramatically and rapidly!

People are now asking AI assistants to research products, compare services, explain policies, recommend suppliers and complete tasks on their behalf. Sometimes, they might not even consciously choose AI and are simply guided by seemingly familiar tools like Google 'AI Overviews'. Either way, instead of visiting ten websites, a customer may ask one assistant to gather the relevant information and present a recommendation. 

In the near future, that AI assistant could be doing more than reading a web page: checking product availability, requesting information, preparing an application, arranging an appointment or even completing a transaction.

Your next website visitor may not be a person at all, but an AI agent acting on their behalf, which raises a serious question:

Can AI systems understand our organisation, trust our information and interact with our services safely?

Getting to know your new audience

To be useful, AI assistants need to find the right information, understand its meaning and decide whether it is current and trustworthy.

A prospective student asking an assistant to compare courses across several universities, a buyer requesting a shortlist of products that meet detailed technical, ethical and budget requirements - both are now part of your website’s audience.

While human visitors use navigation, page layouts, graphic cues and calls to action, AI systems depend more heavily on structured information, descriptive metadata, clear relationships and reliable access to data.

Your web pages may look perfectly clear to a person but remain ambiguous to a machine. For example, a human might understand from the design that one contact address is intended for media enquiries, and another is for customer enquiries, but an AI assistant may not interpret it correctly unless it’s represented clearly in the underlying content structure.

The content management decisions you make today will shape how accurately they are represented by AI tomorrow.

Being visible is not the same as being understood

Many organisations are currently focused on whether their content appears in AI-generated answers. That is important, but visibility is only one part of the problem.

An AI system also needs to understand:

• What the organisation offers
• Which information is authoritative
• When the information was last reviewed
• Which products, services or locations it relates to
• Whether regional or language differences apply
• What actions can be taken
• Which information is public and which is restricted

Without this context, AI assistants may rely on outdated pages, confuse similar services or combine information that was never intended to be used together.

Preparing for AI visitors therefore requires more than content. It requires a well-structured and reliably governed source of truth.

Drupal gives content meaning

Drupal treats content as structured information rather than a collection of web pages. A university course, for example, could have defined fields for qualification, fees and application route, rather than burying them in a block of text. That structure is what makes the same content usable well beyond a single page.

For a human visitor, Drupal assembles that information into an attractive and accessible page. For an AI visitor, the same structure makes the information easier to identify, compare and reuse.

You don't need to maintain one version of content for people and another for machines because Drupal allows the same governed content to serve websites, applications, search services and AI agents.

Drupal can become the trusted source behind AI answers

AI systems are powerful, but they are only as dependable as the information and context available to them. The idea of autonomous agents can quickly become uncomfortable when governance is treated as an afterthought: what happens if an agent uses sensitive information, makes an unsuitable change, or you simply can't tell why an action occurred?

Drupal can provide a controlled source of organisational knowledge. Its content model, taxonomy and relationship system describe what information means, not simply where it appears on a page, helping an AI assistant distinguish a current policy from an archived one, or a general contact address from a specialist enquiry route.

The Drupal AI ecosystem is developing capabilities to support this level of governance, including guardrails for requests and responses, observability and activity logging, controlled access to organisational context, provider-independent integrations, and human review and approval workflows.

This is especially valuable for large or complex digital estates, where information is created by multiple departments across different languages and regions.Drupal's advanced AI implementation and integration does not negate all risk from AI usage, but it does give you a stronger foundation for identifying and managing it

Put simply, AI makes content governance essential to digital communication.

Hi, I'm a machine, please can I come in?

Making content understandable is the first step. The next is enabling controlled action

Giving an AI agent access to your digital platform creates an obvious concern: what will it be allowed to see and do?

Drupal has long supported detailed roles and permissions, allowing different users to view, edit, approve or publish specific types of content.

The same principle can be applied to AI visitors. A useful agent may need to inspect content, search records, or carry out an action, but it should never gain unrestricted access to your systems, or expose private content simply because that content exists in the same system. It should only be able to access the information and tools permitted for the person, service or task it represents.

 The Drupal AI Initiative organises this work through two connected areas:

• Inside AI, which brings AI assistance into Drupal for editors, marketers and site builders
• Outside AI, which enables external AI agents and tools to connect to and act on Drupal

This changes the role of the content management system from being a 'human experience engine' to being a governed platform through which people, applications and AI agents can understand and interact with your organisation.

Design for people, prepare for agents

Human visitors are not disappearing. People will continue to value clear information, strong design, accessible services and experiences that feel relevant and trustworthy. However, they will increasingly use AI to navigate and make sense of the vast amount of information available to them.

AI readiness can look like a technology challenge, but an AI system cannot reliably represent your brand if the underlying content is fragmented, duplicated or poorly structured.

The organisations that adapt successfully will not choose between human-centred design and machine-readable content. They will build digital platforms that support both by creating information people can understand, data machines can interpret and processes agents can interact with safely.

Your next website visitor might not be human - will your digital platform know exactly how to help them?

Try Drupal today!

Article by:  Martin Anderson-Clutz. Originally posted on the Acquia blog.

Drupal turns decoupled architecture into a governed AI harness, combining live visual editing with agent-ready content schemas.

Back in March, at EvolveDigital in Toronto, I ran into Preston So. He mentioned that the team behind Decoupled Days was looking for speakers, and that this year the event would be in Montréal. I was interested right away. Drupal Canvas is the most compelling answer I have seen to a problem that has followed decoupled architectures for years, and I wanted that message to reach beyond the Drupal faithful — out to the practitioners who live and breathe headless every day.

The talk I ended up giving was not really about a content management system at all. It was about how Drupal has quietly become something else: a governed harness for artificial intelligence. Here is the argument I made, the demo that seemed to land hardest with the room, and why I think 2026 is the year the trade-offs of going headless finally stop being trade-offs.

Drupal Was Decoupled Before Decoupled Was Cool

Drupal did not arrive late to the headless conversation. Far from it. The community committed to an API-first architecture roughly a decade ago, and a vibrant subcommunity has been refining decoupled patterns ever since. That work produced a spectrum of delivery models rather than a single one: traditional, where Drupal renders everything; progressively decoupled, where a JavaScript front end takes over the parts of the page that benefit from it while editorial preview stays intact; and fully decoupled, where Drupal is a pure API feeding any number of channels.

That range matters, because it means Drupal has never been only a content API. It owns content, delivery, and governance at the same time. The headless-native platforms compete on one of those axes. Drupal competes on all three.

The Headless Bargain, and Why 2026 Voids It

When organizations adopted front-end frameworks like Next.js and Astro, most of them accepted what I think of as the headless bargain. They gained fast front ends and their choice of framework, and in exchange they gave up live visual editing, layout control, and real-time editorial preview. Editors went from composing pages to filling in form fields blind and filing tickets for changes they used to make themselves.

The industry tried to patch around this — bespoke preview services, visual editors bolted onto the front end, what amounted to Storybook pressed into service as a content tool. None of it fully closed the gap.

Drupal Canvas, which shipped as the default editing experience in Drupal CMS 2.0, closes it a different way. It delivers a true-to-life editing workspace where content creators edit layouts live in the browser, and the site still ships as a high-performance decoupled front end. The CMS stopped being the bottleneck and became the conductor. You keep Next.js or Astro, and you get the editorial experience back.

The Bigger Shift: The CMS Became a Harness

Something larger is happening underneath all of this. For most of the last two decades, the job of a CMS was to model content and publish it to channels. Through 2024 and 2025, artificial intelligence showed up inside these platforms as a feature — an assist button in a text box that summarized a paragraph or suggested tags when a human clicked it.

By 2026, that framing is obsolete. Artificial intelligence has become infrastructure rather than an accessory: autonomous agents that run scheduled jobs, batch operations, and real-time triggers. Analysts have adopted new vocabulary to match, from agentic experience platforms to AI-ready content management. Three capabilities now separate a platform that is serious about this from one that is not: the Model Context Protocol (MCP), which lets external agents query and update content through one standard interface; autonomous agents that behave like digital teammates; and answer engine optimization, which structures content so it surfaces accurately inside tools like ChatGPT and Perplexity.

And the whole category is converging on the same destination. Headless-native platforms like Sanity, Contentstack, Storyblok and others are all racing to add agents, automation, and AI-assisted authoring. When everyone is heading for the same place, the differentiator is no longer whether a platform has AI. It is how that AI is governed and orchestrated.

So What Is an AI Harness?

Even the most capable models today are prone to hallucination, blind to context they are not explicitly given, and easy to push outside the bounds of what an organization would allow. That is why almost no one uses a raw model directly. They use a harness: the code around the model that improves the quality, safety, and reliability of what comes back. A harness augments the query, enforces guardrails on input and output, and adds tools that give the model real capabilities.

Think of your AI model as the engine: the part that makes your reasoning system go. The harness is the vehicle built around it: the controls that point it in the right direction, change gears when the situation calls for it, and bring it to a stop when needed.

If you list what a good AI harness needs — structured content the model can reason over, access control, deterministic workflows, versioned and reviewable configuration, and centralized governance — Drupal has shipped every one of those for years, for reasons that had nothing to do with AI. The model at the center is a commodity. It is swappable, replaceable, and never the true value driver. Everything Drupal wraps around it is the durable part.

Which leads to the line I kept coming back to: what drives the value of intelligent systems is your schema, not your prompt. Prompts are transient. Typed fields, entity relationships, and taxonomy give a model unambiguous ground truth instead of prose it has to guess at. And the same JSON:API structure that feeds your decoupled front end is exactly what an external agent inspects and reasons over. Drupal orchestrates the content and context; the external model supplies the intelligence. That division of labor ages far better than trying to build models in-house.

Where You Actually See It Work

Everything above is architecture. The demo is where it becomes visible, and it is the part of the talk the audience responded to most.

I had set up a demo environment for a fictional company called Inspace. Ahead of time, I populated the Context Control Center with the things a real brand would have on hand: a brand guide, a tone of voice, documentation for a component library I had programmatically migrated from Drupal's Mercury design system into Code Components and synced into Astro, and a set of context items describing a new "Executive Suites" offering that Inspace was preparing to launch.

Then, live, I created a new page in Canvas, opened Canvas AI, and gave it one sentence: generate a landing page for the new Executive Suites offering. It went to work, and while it did, I took questions from the audience. A couple of minutes later it had assembled a full landing page out of real components, populated with relevant, on-brand content. To make the point that a human stays in the loop, I dropped an image from the media library into the hero component and published. Then I switched to the Astro app, navigated to the same path, and there was the identical page — every decision the human and the model had made, rendered by the decoupled front end. A complete landing page, start to finish, in a couple of minutes.

The second beat pushed further. The marketing team wants a brand-new component: a call to action for a waitlist. I asked Canvas AI to build a full-width announcement banner with an announcement pill, a headline, a supporting line, and a primary call to action. After a short pause, the component appeared in the Canvas interface — colors on brand, formatting consistent with the rest of the library — with its code fully visible and editable and a live preview I could resize to check different breakpoints. I noted that in the real world you might refine the code yourself or ask Canvas AI to iterate, then saved it to the library, dragged it into the Executive Suites page, and published.

When I reloaded the Astro app, it threw a fatal error, exactly as I had planned. The layout now referenced a component the front end did not know about. One npx canvas push from the command line synced the components, a refresh brought the page back, and the new banner rendered cleanly in the Astro layout. That deliberate stumble made the architecture legible: content edits flow to the front end instantly, but new component code is a real, versioned artifact that moves through a real workflow.

I closed the demo by going back to the Context Control Center, because that is the intelligence that made the rest possible. This is what AI prompt grounding looks like in practice: before a single token is generated, each request is automatically supplied with the brand voice, domain knowledge, and guardrails relevant to the task at hand. Some context items are global and travel with every request. Others are scoped specifically to working in Canvas. Others still apply only to content about the Executive Suites program. All of them were assembled automatically behind those short prompts — which is why one sentence was enough to get on-brand, relevant output. I finished on the form for managing a single context item, showing the range of ways its use can be scoped and restricted. Compliance before generation, not review after.

Why Enterprises Can Trust It

For regulated and enterprise teams, governance is where this stops being a demo and starts being a decision. Drupal is model-agnostic by design: dozens of providers sit behind one abstraction layer, spanning cloud services like OpenAI, Anthropic, and Gemini as well as self-hosted options like Ollama and Mistral for data sovereignty. Swapping providers is a configuration change, not a rewrite of your schemas or your logic.

Agents act inside Drupal's existing permission model which includes the Access Policy API, so the access logic that already governs your people governs your agents too — no separate guardrail layer to maintain. Deterministic orchestration through the Event-Condition-Action (ECA) or FlowDrop frameworks handle rules-based logic that costs no tokens and never hallucinates, which is a useful reminder that the cheapest, most reliable AI call is often the one you do not make. And because that orchestration lives inside the platform as native state machines — ECA for event-driven rules, Maestro for durable, multi-step approvals — stateful business logic runs where the content lives, rather than being stitched together from external webhooks, serverless functions, and third-party glue code. Guardrails filter sensitive data before it leaves the server, and metering tracks token spend by user and role so finance can see what AI actually costs.

An Honest Read

It doesn't serve anyone to pretend one side wins everything, and I said so in Montréal. The headless-native platforms lead on real things: faster time to value, a cleaner developer experience, and more polished agentic tooling in market today. If those are your priorities right now, they are genuine strengths.

Where Drupal leads is open source with no lock-in and dozens of documented APIs, model-agnostic freedom, deep governance and orchestration, and fit for enterprise, multi-brand, and regulated environments. It is also worth remembering the shape of the thing behind it: an open ecosystem moves at the speed of everyone who needs it to, while a single-vendor roadmap moves at the speed of one company's priorities.

The Takeaway

The way I put it at the end of the talk: we gave up the editorial experience to go headless, and in 2026 we stopped having to. The original headless win is now additive with the editorial win, not traded against it. One structured content model can serve four consumers at once — a decoupled front end, editors in Canvas, internal AI agents, and the wider martech stack over MCP.

Drupal is not a CMS with AI features bolted on. It is a governed AI harness that happens to have been building the right foundations for 20 years. If you want to see it for yourself, start with Drupal CMS 2.0 and Canvas, then explore the AI, context, and MCP modules. For teams that would rather not set up and host Drupal themselves, Acquia Source CMS offers a fully managed on-ramp to the same platform. And if you are ready to help shape where this goes, the Drupal AI Initiative is where the work is happening.

Making that case in Montréal was a highlight of my year. If you were in the room, thank you — the questions were sharp, and a few of them changed how I will explain this next time. If you were not, come find me, and we can pick up where the talk left off.

This is cross-posted from Mike Herchel's blog

A few weeks ago, I met up with some of the DrupalCon Orlando local planning committee at the Hyatt Regency Grand Cypress Resort to check out the venue and finalize a bunch of plans.

We toured the resort, planned events, sampled food and drinks (strictly for quality assurance, of course), floated around the pools, and spent way too much time talking about all the fun stuff we're putting together.

After seeing everything in person, I'm convinced this is going to be the best DrupalCon ever!

This DrupalCon is going to feel different (and I think that's a good thing)

If you've been to previous DrupalCons, one thing you'll notice right away is that this one is going to have a different vibe. Normally we're in a downtown convention center where you can walk to bars, restaurants, coffee shops, and whatever else you stumble across.

This isn't that. The Grand Cypress sits in the middle of Orlando's resort area near Disney. If you want to leave the property, you'll probably grab an Uber or Lyft. Disney Springs is only about 10 minutes away, and the parks are just beyond that.

But honestly... I don't think most people are going to want to leave. This resort is awesome.

Instead of everyone scattering around downtown after the sessions end, I think we're going to end up hanging out together around the resort having poolside cocktails, or smores by the fire pits. And after spending the weekend there, I think that's going to make for an even better conference.

The pools are ridiculous

Seriously. The pool area is unlike anything we've ever had at a DrupalCon.

The pools wind around faux limestone cliffs with waterfalls pouring down into them. There's a cave that connects two sections of the pool, a grotto, a waterslide, two hot tubs, and tons of places to spread out.

Then you've got a poolside bar serving frozen drinks, beer, and food just a few steps away. I can already picture dozens of Drupal people hanging out there after sessions.

Florida in March is basically cheating

If you're coming from somewhere that's still cold in late March... congratulations. This is probably the nicest time of year to be in Florida.

Expect highs around 80°F (27°C), cool evenings, blue skies, and weather that's pretty much perfect for sitting outside all day. It's warm enough to swim without feeling like you're melting.

One of the nicest surprises is the hotel rate that we have. The Drupal Association was able to lock in an incredible rate of just $259/night, and that includes no resort fee. Considering this is one of the best times of year to visit Florida (and a resort like this!) it's an amazing deal. If you're planning to attend, book sooner rather than later:https://www.hyatt.com/events/en-US/group-booking/VISTA/G-DC27.

Everything is actually close together

This might sound boring compared to waterfalls and waterslides, but trust me, it matters. One thing I loved about the venue is how compact the conference space is. No hiking across giant hotel lobbies or speed-walking half a mile to your next session. No wondering which section your talk is actually in.

Everything is clustered together, which means less walking and more time talking to people in the hallways, which is the best part of every DrupalCon anyway.

Drupal's Got Talent is finally happening!

I've been trying to make this happen for years. Every DrupalCon I’d pitch the idea of a talent show, and every year something got in the way. Well... this is the year! It’s happening!

We'll be looking for pretty much anything entertaining:

• Musicians
• Bands
• Stand-up comedy
• Magic
• Singing
• Dancing
• Juggling
• Puppet shows
• Weird talents you didn't think anyone wanted to see (we do)

We’re not taking sign-ups just yet, but keep an eye out!

What should you pack?

Besides your laptop?

• 👙 A swimsuit (trust me)
• 🩴 Flip-flops or sandals
• 😎 Sunglasses
• 🧴 Sunscreen
• 👕 Clothes for warm afternoons and cooler evenings
• 🎤 Your hidden talent

This venue is a little different than what we're used to, but after spending the weekend there, I know it's going to create a totally different kind, and super memorable, DrupalCon.

Instead of everyone disappearing into the city after the sessions end, I think people are going to stick around. Hanging out by the pool. Sitting around the fire pits. Grabbing a drink. Talking Drupal late into the night.

And honestly? I can't wait!

As Drupal agencies, we're fortunate to benefit from a vibrant ecosystem that generates awareness, interest, and opportunities for all of us. At Zoocha we receive inbound enquiries from a variety of sources. Whether they arrive via Drupal AI, Drupal CMS, a community recommendation, a Drupal event, or direct through our site, every enquiry often represents something important: a person taking their first step towards our community.

Not every lead is a project. 
Not every lead has a budget. 
Not every lead is ready to buy. 

But they always deserve a meaningful response. 

The First Impression of Drupal 

When someone reaches out to a Drupal agency, they're rarely just evaluating that agency, they’re more often than not seeking to engage with Drupal itself. For many prospective clients, they may not know the difference between Drupal, the Drupal Association, Drupal CMS, an implementation partner, a hosting provider, or the wider open source community. They simply know they've heard about Drupal and are looking for guidance. 

The response they receive helps shape their perception of the entire ecosystem. If their first interaction feels dismissive, transactional, or overly focused on qualification, they may walk away believing that's what the Drupal community is like. If their first interaction is friendly and genuine, they leave with a very different impression. 

Resist the Urge to Qualify Too Early 

Most agencies have some form of qualification process. It's sensible, and so do we. Time is valuable, and we know not every conversation will become a project.

However, there is a difference between understanding someone's needs and interrogating them. We've all seen responses that immediately ask:

• What's your budget?
• What's your timeline?
• Have you secured funding?
• How many pages does the site need?
• Can you complete this requirements questionnaire?

While those questions have their place, they are rarely the most important thing during an initial conversation. Many prospects simply don't know the answers yet.

Some are conducting research. Some are exploring options. Some are trying to understand whether Drupal is even the right fit. At this stage, what they often need most is guidance.

Be Helpful Without Expectation 

One of the most effective approaches we've found at Zoocha is to assume that the first conversation may never lead to a sale. That does sound counterintuitive for a commercial organisation, but it changes the nature of the interaction. Instead of trying to move the conversation towards a proposal as quickly as possible, we focus on being useful. That might mean:

• Answering questions about Drupal CMS
• Explaining how Drupal compares to other platforms
• Pointing someone towards community resources
• Offering advice on procurement approaches
• Helping clarify requirements
• Suggesting next steps, even if they don't directly involve us

Sometimes that conversation ends there, and that's ok. The contact doesn't leave empty handed. They leave with a positive impression of who we are in the Drupal community.

The Long-Term Value of Community-First Thinking 

Interestingly, some of our most successful client relationships started with conversations that had no immediate commercial outcome. We've had early exchanges that were little more than an idea, with individuals facing a specific challenge and just looking to find out if they're even in the right place with Drupal. After a person-first conversation, they disappeared. But a few months, or even a year, later, they came back, and what began as a casual enquiry became a long-term client partnership.

This didn't happen because we had the best sales team or process. It happened because we prioritised human connection over a fast sale.

Open Source Values Apply to Business Development Too 

Drupal has always been built around principles of collaboration, openness, and knowledge sharing, these values really shouldn't stop at code contributions. They can also shape how we engage with prospective users of the platform. When we answer questions generously, share expertise freely, and help organisations make informed decisions, we're strengthening confidence in Drupal itself. 

Even if a particular opportunity never becomes a client engagement, the person on the other end of that conversation is left with a positive impression of the community. That's good for all of us! 

Conclusion 

The next time a speculative Drupal enquiry lands in your inbox, try viewing it differently. Consider simply asking, "How can we actually help this person?" The answer might only require a short email, a useful link, or a brief conversation, and yes, the immediate commercial return is likely to be zero. But the long-term return, for your agency and for the Drupal ecosystem, can be significant.

Every first interaction is an opportunity to demonstrate what makes the Drupal community different. Let's make sure it's a positive one.

This post is adapted from the DA Insider, the Drupal Association's monthly newsletter. Subscribe here to get it in your inbox each month.

A note from our interim CEO

Dear Drupal community,

Open source hums along on the work that just gets done. As I step into the interim CEO seat, I'm making a point to notice the sheer volume of work powering this ecosystem, from the DA and beyond. Here's some of what has come together in the past month:

• Our engineering team migrated hundreds of projects to GitLab, security issues included, and kicked off an RFP to make launching a Drupal site dead simple.
• DrupalCon Rotterdam is ready and in the homestretch.
• The DrupalCon Orlando call for speakers opened August 4. If the event converts even half the enthusiasm of the local team (or the cuteness of Bytes the Gator), it's going to be one to remember.
• We're building a new front door to introduce Drupal to new audiences and evaluators, and we're looking for help.
• The community has 14 global events dropping this August and partnership groundwork under way in Burkina Faso.
• Nominations are open for the Women in Drupal Award, an honor I was humbled to receive back in 2023.

My goal as interim CEO is straightforward: make sure the Association's foundation is resilient enough to support all this energy. The first step is helping all of us notice and appreciate the work that already "just happens."

I hope you enjoy this month's newsletter and everything everyone's been building. And one final note: board elections are open. Please vote.

Tiffany Farriss Interim CEO

Vote in the 2026 At-Large Board Election — closes 14 August

If you're a Ripple Maker, your ballot arrived by email from Helios Voting on 22 July. Voting closes 14 August 2026 at 23:59 UTC, so there's still time to get to know the candidates: read their profiles and leave questions on the election details page, catch the Open Community Forum recording on our YouTube channel, or revisit the async conversation in #drupal-association on Drupal Slack. Every vote counts — make yours matter.

DrupalCon Rotterdam is in the homestretch

DrupalCon Rotterdam 2026 is ready. Join the global Drupal community for four days of learning, collaboration, and connection — explore the program, meet the speakers, and start planning your experience. Secure your ticket now.

DrupalCon Orlando 2027: Call for Speakers is open

The DrupalCon Orlando 2027 Call for Speakers opened 4 August and closes 20 October 2026, with some notable changes this year:

A more focused program with fewer concurrent sessions and an emphasis on high-quality, impactful content. Updated session tracks reflecting the evolving Drupal ecosystem. And a new pathway for first-time speakers: if you've never spoken at a DrupalCon, DrupalCamp, or other Drupal event, you can submit to the new Poster Session — selected presenters showcase their work at the Monday Welcome Reception and present a 10-minute session on the Lightning Stage.

And keep an eye out for Bytes the Gator, the DrupalCon Orlando mascot, who'll be visiting Drupal events around the world between now and March 2027 — with a chance to win a free registration to DrupalCon Orlando 2027 along the way.

Celebrate the women shaping Drupal's future

Nominations are open for the Women in Drupal Award, sponsored by Jakala, recognising women whose work strengthens the Drupal community — in the projects they build, the teams they support, the ideas they bring forward, and the space they create for others to grow. Know someone whose contribution deserves recognition? Submit a nomination.

Drupal Steward: extra time when it matters most

When highly critical vulnerabilities emerge — like SA-CORE-2026-004, a SQL injection in Drupal core that anonymous users can trigger — every minute matters. Drupal Steward is a security service from the Drupal Association that gives you extra time to respond before vulnerabilities can be widely exploited: early notification of highly critical issues, recommended WAF mitigation rules, and access to security expertise, in coordinated collaboration with the Drupal Security Team. It's available in a Community Tier for smaller site portfolios, plus Small, Mid-Size & Enterprise tiers for organisations that want full control. Referral incentives are available for Drupal Certified Partners.

Behind the scenes with the engineering team

The migration of projects to GitLab issues continues — including security issues and hundreds of Ripple Maker projects — with GitLab soon to be enabled by default for all new projects, alongside updated contribution docs and a new custom commands reference. The team has also kicked off a collaboration with Alpha-Omega through their Security Engineer in Residence program to triage and respond to the growing wave of AI-generated security reports. And an RFP is under way for the Drupal Site Template Marketplace, focused on closing the last mile from template selection to live hosted site.

Help build Drupal's new front door

We're building a dedicated product marketing site for Drupal — a purpose-built, marketing-led site designed to reach the people who haven't heard of Drupal yet: marketers, IT directors, and enterprise decision-makers evaluating CMS platforms.

High-priority tasks are being added to the promote_drupal project on GitLab — real, scoped pieces of design, content, video, and strategy work with significant contribution credits attached, with more added on a rolling basis. If something catches your eye, reach out to Ryan Witcombe at ryan.witcombe@association.drupal.org or @RyanWitcombe on Drupal Slack.

A milestone for open source in West Africa

On 15 July, the Drupal Burkina Faso Association, led by its president Seferiba Salif Soulama, met with Burkina Faso's Minister of Digital Transition, Dr. Aminata Zerbo/Sabane, to explore how Drupal can support the country's digital future. The meeting marks a significant step toward a formal partnership between the Ministry and the Drupal Burkina Faso Association, with Drupal at the heart of Burkina Faso's digital modernisation agenda.

This is what open source looks like in action: communities, governments, and technology coming together to build something that belongs to everyone. Read the full story.

One more thing: The AI Byte

The Drupal AI Initiative team has launched The AI Byte, a monthly LinkedIn newsletter curating the best content across the web about Drupal AI — new capabilities, case studies, events, and webinars. Subscribe on LinkedIn.

This roundup is adapted from the DA Insider, the Drupal Association's monthly newsletter. Want it in your inbox? Subscribe to email communications and browse previous editions.

AI was used to help adapt this newsletter into a blog post. It was reviewed and edited by Drupal Association staff before publishing.