fidzu : Drupal

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.