Last year, I got to play chess against him. This time, I got to tell a room full of people why I admire him.

It was a memorable evening for me, and I wanted to capture it here by sharing my speech.

Good evening, everyone.

I'm Dries Buytaert, a Belgian technologist. I created Drupal, Open Source software for building websites.

I've been asked to introduce Garry Kasparov and share some of my own thoughts on AI along the way.

Think of me as the warm-up act.

As I was preparing for tonight, I realized Garry and I have something in common. We both had a big year at the age of twenty-two. I released the first version of Drupal. And Garry became world chess champion.

My launch attracted slightly less attention.

At the time, Garry was the youngest world chess champion ever. And he spent about twenty years as the world's number one.

Last year, thanks to Inge Geerdens and Your Next Move, I got to play Garry myself. That was a dream come true. For me, he's the greatest chess player of all time.

He was playing against twenty of us at the same time. I knew I was going to lose. The only question was in how many moves. Garry won all twenty games, and I lasted twenty-five moves.

He might not remember our game, but I'll remember it for the rest of my life.

I played the Caro-Kann Advance Variation and was out of book after six moves.

Long before our game, Garry's games against a computer made headlines around the world. In 1996, Garry beat IBM's Deep Blue. But a year later, Deep Blue won the rematch.

For the first time in history, a computer, equipped with AI, had beaten the world chess champion in a full match.

Some people make history by being the first to climb Mount Everest. Others, by being the first to walk on the moon.

Garry made history nearly thirty years ago ... as the first knowledge worker to lose his job to AI.

Garry, on behalf of everyone in this room ... thank you for going first.

A quick show of hands: who here has wondered, "What does AI mean for my job?".

What I really admire is what Garry did after his loss to Deep Blue. He immediately turned around, embraced AI, and explored how it could make him a better player. That takes an open mind, confidence and curiosity.

Today, it's our turn to rethink how we work and learn with AI. AI is changing how we compete, and what it takes to stay ahead.

If you run a business, you know how quickly competitors can learn from your success. In top-level chess, your games are recorded and stored in a public database. Your competitors can study them, move by move.

Garry had to keep improving while his competitors were learning from him. And when he retired from professional chess in 2005, he was still number one.

With Drupal, we compete in the open, too. Drupal has powered millions of websites around the world. Drupal is Open Source, which means anyone can use it for free, study the code, copy it, and change it. All for free.

Open Source democratizes access to technology. And it gives people more digital sovereignty: more control over the tools they depend on.

But it also means our competitors can start with the same code. We even give them the installation instructions and the manual.

When Garry and I played last year, we started with the same chess pieces. In exactly the same positions.

It turns out that is not enough to win.

Not for me. And not for the other nineteen players he beat.

Having the same tools doesn't mean you get the same results. And that is true in business, too.

Your competitors have access to the same AI tools you do. What matters is the expertise and judgment you bring, and how well you understand your customers.

And our choices about AI matter beyond business, too. AI is changing geopolitics. It's changing who holds power.

We've all seen those photographs of world leaders meeting the heads of technology companies. Those companies are now helping to shape national security, energy, and the economy. With that influence come questions about how we protect freedom and democracy.

For me, technology is at its best when it gives people more opportunity and more control over their own lives. That's what motivates me in Open Source. And it's what excites me about AI.

It's also why I value Garry's perspective.

Garry earned the world's attention through chess, then used his voice to stand up for the freedom of others, including the people of Ukraine.

For twelve years, Garry chaired the Human Rights Foundation. Today, he is the founder and chairman of the Renew Democracy Initiative.

For more than twenty years, he has stood up to Vladimir Putin and fought for a free and democratic Russia. He even tried to run for president.

Last year, some of us had dinner with Garry. Someone asked him what he still wanted to achieve in his life.

His answer has stayed with me.

He said he wanted to be able to visit his mother's grave in Russia.

Because of his opposition to Putin, he cannot safely return.

For Garry, freedom is deeply personal.

That combination of curiosity about technology and commitment to people is why I'm so glad he's here to talk about the future of AI.

Please join me in welcoming the thirteenth world chess champion, author, and advocate for freedom and democracy ...

Garry Kasparov.

To let assistants find and edit my photos, I used the contributed Tool module, which provides Tool API, to expose my module's operations as tools. These include finding photos and updating a photo's caption or alt text.

Most of these tools are public methods on Drupal services I already had, like the one that searches my photos. A few PHP attributes are usually enough for Tool API to expose an existing method, so AI assistants can call it over MCP, the Model Context Protocol.

To describe a tool to other software, Tool API needs to know what data it accepts and returns: what each value is called, what type it is and what it means.

My album module doesn't store photos as Drupal entities (I know, I know), so Drupal has no field definitions for them. Instead, it keeps them in its own database table and loads each photo into an instance of Image, a plain PHP class. I added PHP attributes to the getters for the properties I wanted to expose, like this one for the alt text:

#[ToolProperty(description: 'Plain text describing the image for screen readers.', media_type: 'text/plain')]
public function getAlt(): string { 
  ... 
}

From attributes like this one, Tool API generates JSON Schema, a format for describing JSON data. MCP and OpenAPI, a standard for describing HTTP APIs, both use this format. So do Drupal's Single Directory Components, which use it to describe the data passed to reusable interface components.

In my album module, I use the same descriptions of my photo data to tell AI assistants what my tools return, generate TypeScript types for a React app that searches my photos, and define the inputs for my Drupal components.

The same tools also connect my site to various workflow systems. A workflow built with ECA, FlowDrop, Maestro, n8n or Activepieces can call the same photo-search tool an AI assistant calls, without requiring a separate integration with my album module.

A module maintainer exposes an operation once, and several kinds of software can use it.

This is why I said in my keynote that I believe the Tool module, built by Michael Lander and team, is one of the most important modules in Drupal right now. A module's capabilities can become available to assistants, front ends and workflows without its maintainer having to build for each one separately.

I think every Drupal module should work this way, which is why I featured it in my keynote and why I launched a broader effort around this called Rosetta.

The goal is for Drupal's own systems and software outside Drupal to work from shared descriptions of data and operations. Below, I'll walk through what I built and tested with my album module.

Drupal needs shared descriptions of data and operations

More of the work on a site happens outside Drupal every year: in AI assistants, in front ends built with JavaScript frameworks, and in orchestration platforms that connect Drupal to other systems. As I explained in AI and the great CMS unbundling, those systems still need the content management, governance and observability that Drupal already provides.

Drupal has entities, fields, permissions, revisions, workflows, content moderation and tens of thousands of contributed modules. But making a module's capabilities available to an assistant, a workflow or a front end still too often requires some integration work.

Installing a Drupal module should make its capabilities available to software already connected to a site: new tools for assistants, new operations for workflows, and new capabilities for front-end developers.

In my album module, I should only have to describe a photo once and implement photo search once, not write a separate integration for every assistant, front end or workflow system.

In Drupal, we already know why shared descriptions matter. When a site builder adds a field to a content type, Drupal stores a definition for it: its type, its label and whether it's required. Content editing forms, Views and JSON:API all reuse that definition.

CCK, Drupal's Content Construction Kit, let site builders define a field once, and Drupal used that definition for the edit form, the display and the database. Views let them list, filter and sort data from any module that described its data. Rosetta is about extending that kind of reuse to more of a module's data and operations.

Shared descriptions of data and operations could be Drupal's next CCK and Views moment.

User interfaces also keep changing: web pages, then native mobile apps, then headless front ends, then chat, and now AI assistants and agents. I don't know what comes after agents. But if modules describe their data and operations, new interfaces can build on the capabilities we already have. The next interface reads the description and gets to work. That won't make Drupal immune to change, but it makes us fast to adapt, and fast to adapt helps us win.

The question then becomes how to make that practical for thousands of module maintainers. Tool API gives us a starting point, alongside years of work on Typed Data, Single Directory Components, JSON:API, Drupal Canvas Code Components, Modeler API, and more. We need the people behind that work to help shape the approach, including whether Tool API, or parts of it, belongs in Drupal Core.

That's why I'm organizing the Rosetta Sprint: a few days for the people behind these projects to get together in person to compare the existing approaches, identify what is missing and agree on next steps with the relevant maintainers and Core committers.

Describe existing data and expose functions as tools

Tool API supports two ways to define a tool: (1) you can write a dedicated plugin class that Drupal discovers as a tool, or (2) add PHP attributes to an existing public method on a class registered as a Drupal service.

I started with a dedicated plugin class but ultimately switched to PHP attributes. Attribute support was still experimental when I started, and I helped improve Tool API as I used it (#3583030, #3583031, #3583032, #3583041, #3583085). The attribute support is now merged and available in Tool API's development version. Dedicated plugin classes remain fully supported.

I'll show the basic pieces here rather than walk through a full tutorial. Here is how the method that searches my photos becomes the find_images tool, simplified a little:

/**
 * Searches the images.
 *
 * @param string $query
 *   Words to look for in the title, caption or alt text.
 *
 * @return \Drupal\album\Image[]
 *   The matching images.
 */
#[ToolMethod(
  id: 'find_images',
  label: 'Find images',
  description: "Searches the site's images. …",
  operation: ToolOperation::Read,
  permission: 'access content',
)]
public function search(string $query): array {
  // The search code is unchanged.
}

The method body stays the same: it takes a search query and returns the matching images. The #[ToolMethod] attribute gives the tool its ID, label and description. It also declares that the operation reads data and that the caller needs the access content permission. The search code must still enforce any restrictions on which photos the caller can see.

Tool API reads the input's name and type, query and string, from the method signature. When type information is missing, Tool API tries to infer it from the method signature and docblock. Here, the Image[] return annotation tells Tool API that the array contains Image objects.

Knowing that the result is a list of Image objects doesn't tell other software which properties a photo has. I describe those with #[ToolProperty] attributes on the Image class's getters, like getAlt() above.

The attributes also explain what each property means. In PHP, a title, a caption and a URL can all be strings, but other software needs to know which is plain text, which contains HTML and which is a URL. I illustrated that distinction in the keynote:

Tool API only includes the photo properties I explicitly describe with #[ToolProperty]. The attribute can go on a public class property or a getter method. On getUrl(), it exposes the returned value as a photo property named url; it doesn't make the getter a callable tool.

Under the hood, Tool API uses Drupal's Typed Data API to represent these descriptions and can generate JSON Schema from them.

Drush, MCP, ECA, FlowDrop, Maestro and my album module's custom HTTP route can all call the same runner, ToolRunner::run(). That means the same permission checks and input validation apply whichever way a tool is called. The runner also distinguishes invalid input from denied access or an execution failure, so each integration doesn't have to work that out for itself.

As mentioned, PHP attributes aren't the only way to define a tool. A dedicated plugin class is a bit more verbose, but it has some advantages. For example, it doesn't have to live in the module it exposes. A separate module can define the tools and call the original module's services and APIs, with no changes to its code. Tool Belt currently takes that separate-module approach for Drupal Core operations, like creating content and updating fields. That means we can add tool support for existing modules without waiting for their maintainers to adopt Tool API.

If you maintain a module, try exposing one useful operation as a tool. If you get stuck, or Tool API can't describe the data you need, open an issue. Your feedback can help us improve Tool API before its first stable 1.x release. Tool API is still young, so you can help shape it.

AI assistants can handle complex tasks without developers

I actually started with search. A while ago, I exposed my blog's search to AI agents and wrote about it several times: as an MCP tool, through an API catalog and with Agentic Resource Discovery. That code started out custom, but I've since updated it to use Tool API as well.

Later, I added the album tools. My album module provides seven. The ones I use most are find_images and get_image, which find and read photos, and update_image, which changes a photo's title, caption or alt text.

I've used these tools to write titles and alt text for whole albums. Here are a few other things I ask an assistant to do:

• Find every photo that still has no alt text, across all albums, and suggest alt text for me to review.
• Find typos or grammar issues in my captions.
• List the photos in an album that have no title, and suggest titles for me to review.

The album tools and find_posts often work together. If I have an album from a trip and a blog post about the same trip, an AI assistant can call find_posts while it writes alt text for the album's photos, and use the post as context. It picks up details such as where we went, who was there and what the trip was for. The alt text gets better, without me having to point the assistant at the post.

My album module's admin screens can't do any of these tasks quickly, and some tasks have no screen at all. Before these tools, I either had to run SQL queries on the database or didn't do the task at all. To fix missing alt text, I'd query for the photos without it, then open each photo's edit screen in a browser. Updating dozens of images that way gets tedious.

Now an assistant finds the photos and drafts the alt text, and I review and approve its suggestions in Claude. It's at least 10 times faster than my old workflow.

I've been writing SQL for nearly 30 years, so I could always do these jobs myself. Many site owners can't. They ask a developer for help, or the job never gets done. Tools can remove that dependency. Photos are just my example. Any operation a module exposes as a tool becomes something a site owner can ask for directly, without waiting for a developer.

AI assistants can handle complex tasks without dedicated UIs

When an assistant calls get_image, it gets the photo's properties and the photo itself, so it can see what it's describing. In Claude, an interface I built also displays the photo in the chat. It uses MCP Apps, an MCP extension that lets a server provide an HTML interface the client renders in the conversation.

Every module has tasks that are too rare or too specific to justify a screen of their own. A maintainer can build screens for everyday work and make rare or specialized tasks available through tools. I've already removed parts of my album module's interface, like the button that generated alt text with a language model, because an assistant now does that job. I expect to remove more.

Shared descriptions can also make it easier to tailor interfaces to the people using them. Tool API can already generate a form from a tool's inputs and apply the same validation constraints when the tool is called without a form. Michael Lander is exploring this further in his Data Surface prototype, where forms and tools use the same definitions of accepted values and validation rules.

An organization could build admin screens around its own workflow while reusing those definitions and validation rules. With the right prompting, assistants can already build interfaces around these tools. For a batch of photo updates, that could be a table of images and proposed alt text where I can review and approve the changes. Over time, I expect assistants to recognize when an interface would help with a task and build one without being asked.

Michael's work builds on Drupal's configuration validation, and it is a good example of what I mean when I say Drupal has an accidental AI advantage. Wim Leers began advocating for configuration validation in 2022. AI wasn't part of his case. Years later, Michael can reuse those validation constraints to power forms and tools from one definition, and in Validation-first, Wim describes how the same precision helps AI tools generate valid Drupal Canvas code components.

JavaScript front ends can use the same tools as AI assistants

But that is not all. With my album data and operations described, I decided to make the same data and tools available to front-end developers. I wrote two pieces of connecting code: a shared HTTP route that calls read-only tools, and a generator that produces an OpenAPI document from their definitions. Together, they take under 150 lines of PHP.

The route uses the URL to identify the tool and the query string to supply its arguments. For example, a request to /api/find-images?query=ski calls find_images with ski as its query and returns the result as JSON. I didn't write another photo search or a separate route for each tool.

The auto-generated OpenAPI document, available at https://dri.es/openapi.json, describes those endpoints, their parameters and their responses. It uses the same #[ToolMethod] and #[ToolProperty] attributes the MCP tools use.

OpenAPI is a 15-year-old standard for describing HTTP APIs, so it's supported by many developer tools. Swagger UI, for example, lists my endpoints and lets you try them. This video shows the document, then Swagger UI reading it and calling the API for "driesnote":

Many front-end developers use TypeScript, which adds static types to JavaScript. A type can describe an image as an object with a string alt and a string title. The TypeScript compiler checks the code against those types before it runs, and editors like VS Code show type errors as you write.

To see what this gives a front-end developer, I asked Claude Code to build a small React app that searches my photos from the browser. The app knows nothing about Drupal, and building it didn't require any Drupal knowledge either. All Claude Code had was my site's URL and its generated OpenAPI document.

I'm not a front-end developer, so it was interesting to watch. Claude used a code generator called openapi-typescript to turn my OpenAPI document into TypeScript types in under a second. A small library called openapi-fetch then uses those types, so the compiler can check the request paths and parameters in the app's code.

The whole app is a single React component of 45 lines, and I wrote no additional Drupal code for it. In this video, it searches for "driesnote":

The HTTP route and OpenAPI generator are prototype code on my site. Nothing in them is specific to photos, so they shouldn't be something each site or module has to write. They belong in shared infrastructure that works for any module's tools. JSON-RPC is one place that could happen: if JSON-RPC supported Tool API, it could expose tools from other modules without each module writing its own JSON-RPC integration.

Workflows can call module operations as tools

Inside Drupal, ECA, FlowDrop and Maestro can call tools as steps in a workflow. The ECA Tool module, for example, makes tools available as ECA actions.

In the keynote, Shibin Das showed a FlowDrop workflow he built with my album module's tools. It searches my photos and lists my albums, first without any AI, then with an agent that decides which tools to use:

Workflow systems can also expose tools of their own. ECA calls its workflows "models", and the ECA Tool module exposes each Tool event in a model as a separate tool. One model can therefore offer several tools. Maestro can expose public workflow templates as tools, using their variables as inputs.

A workflow that is also a tool can be used like any other tool. A Maestro workflow can call a tool exposed by ECA, through the same Tool API integration it uses to call my photo search. Neither system needed a direct integration with the other. I still find that a little hard to get my head around, but I love it and see the potential.

Automation platforms outside Drupal need a way to call those tools too. Last year, Jürgen Haas and I built the Orchestration module to connect Drupal with Activepieces. It lets Activepieces call tools defined through Tool API, run AI agents and trigger ECA models, while events in Drupal can trigger workflows in Activepieces. I described that setup in Connecting Drupal with Activepieces. Other platforms can call Drupal's tools over MCP, for example through n8n's MCP Client node.

Tools compose. An assistant can combine them in a single task, a workflow can chain them, and a workflow can be one of the tools in another workflow. Once a system can call Drupal's tools, it can reuse that connection for operations from different modules.

That is the orchestration shift: a stack becomes a network, and workflows coordinate work across applications. Drupal can be a node in that network, with its modules offering operations that other systems can call. For agencies building those workflows, Tool API makes Drupal's capabilities available as reusable steps.

Drupal components can share data descriptions

So shared descriptions help JavaScript front ends and other applications use Drupal's data, but they can also help Drupal's own rendering system, even when no AI assistant or external application is involved.

My photos are rendered using Single Directory Components, or SDCs. Each component keeps its Twig template, CSS and metadata in one folder. Its .component.yml file declares the component's inputs, called props, and describes the data they accept.

My album module already describes a photo's properties with #[ToolProperty] attributes. I was also maintaining descriptions of those same properties in each photo component's .component.yml file. When I changed what a photo property contained, I had to remember to update both descriptions.

So I wrote a Drush command that reads the PHP attributes and generates a shared schema.json file. My album module's generated photo schema describes properties such as alt and caption: their types and what they contain. Each photo component's .component.yml file now references that shared description instead of describing those properties again. When I change what a photo property contains, I update its PHP attribute and run the command.

Moving the descriptions into a shared file creates a new problem. Anything that reads a component's .component.yml now finds a reference to schema.json, not the property definitions. A tool that builds a component catalog, showing what data each component expects, has to find and resolve that reference itself. Core's component API doesn't do it for them: it returns the reference without the photo's property definitions.

Pierre Dureau's merge request in Core issue 3352063 addresses that gap, though it isn't merged yet. With it applied on my site, Core's component API followed the reference and loaded the photo property definitions, without any changes to the schema file.

That matters for generative UI. Frameworks like OpenUI and A2UI let an AI agent assemble an interface from a catalog of components, so they need to know which components exist and what props each one accepts. With this change, an integration could build that catalog from Drupal's API instead of writing its own reference resolver. Tools that read the component files directly still need to learn to follow these references. The SDC add-on for Storybook, a tool for developing and previewing components, doesn't yet follow the Drupal-specific references I use.

The same goes for the generator. Other module maintainers shouldn't each have to write one like mine. My experiment uses Tool API's property descriptions, but describing data and generating schemas are useful beyond tools. Some of that support could belong in Drupal Core, benefiting both SDC and the Icon API, which uses JSON Schema to describe icon settings such as size and color.

My approach only covers components built to render my module's photos. General-purpose components define their own inputs and still need a way to get Drupal's data. Drupal describes entity fields with Typed Data, while SDC describes props with JSON Schema. UI Patterns already handles much of the work between them, including which data sources can supply a prop. Rosetta should build on that work too.

Make shared descriptions standard practice

The same photo descriptions and operations now support AI assistants, a React app, workflows inside and outside Drupal, and Drupal components.

I want more module maintainers to adopt Tool API: describe their modules' data once and expose useful operations as tools. That should become a normal part of developing and maintaining a Drupal module.

We should also provide the HTTP integration, OpenAPI generator and component schema generator as shared Drupal infrastructure. Module maintainers shouldn't each have to write that connecting code.

My prototypes show this working for one module. Rosetta is about making that reuse work across Drupal. We need to work with the relevant maintainers and Core committers to decide what belongs in Tool API, its integrations and Drupal Core.

If you maintain a module, try exposing one useful operation as a tool and using it with another system. Share what worked, and open an issue when you find something Tool API can't describe or do.

Thanks to Jamie Abrahams, Mateu Aguiló Bosch, Ronald te Brake, Shibin Das, Pierre Dureau, Matt Glaman, Jürgen Haas, Marcus Johansson, Randy Kolenko, Michael Lander, and Fons Vandamme for reviewing this post.

Just over two years ago, I launched Drupal Starshot. I did it because I wasn't sure we could still innovate like we used to. It turns out we can.

Starshot became Drupal CMS, which brings together Site Templates, Recipes, Drupal AI, Drupal Canvas and more to make building websites easier.

Alongside that work, Drupal Core has become a faster and better framework for developers. A stronger Drupal Core helps us build a better Drupal CMS, while building Drupal CMS has driven further improvements in Drupal Core.

Unfortunately, many people outside the Drupal community haven't seen what Drupal can do today. In Rotterdam, I showed how far we have come and where we're going next, and we launched an advocacy program to help more people see how great Drupal has become.

If you missed the keynote, you can watch the video below or download my slides (86 MB).

More ways to reach more people

The first part of my keynote showed improvements for multilingual sites, JavaScript front-ends, headless Canvas, and Drupal AI.

Drupal has long had strong multilingual capabilities, but Drupal Canvas, our powerful new page builder, didn't yet support multilingual sites. Not only did we add multilingual support to Canvas, but we made all multilingual sites easier to set up.

React has one of the world's largest developer communities. Drupal Canvas code components are written in React, and we designed the developer experience around the tools, patterns, and workflows front-end JavaScript developers already know. They can use their preferred development tools, including modern AI-assisted workflows, without having to learn Drupal-specific concepts or conventions. We've continued to make that experience better, lowering the barrier for a much larger community of developers to build with Drupal.

At DrupalCon, we extended that same model with Drupal Canvas Headless. Developers can now use Drupal to manage content while building the front-end separately with frameworks like Next.js, Astro, TanStack, Angular, or Nuxt. Editors still get the visual experience of Drupal Canvas: they can build pages in Drupal and preview exactly how those pages will appear on the front-end.

This changes an important trade-off. Teams no longer have to choose between a modern JavaScript front-end and Drupal Canvas' visual authoring experience. They can have both. That opens Drupal to more developers, more front-end architectures, and more types of projects.

Drupal AI is moving so fast that I could have filled a whole keynote with it. Instead, we launched a new Drupal AI demo where people can experience Drupal AI for themselves. It comes preconfigured, making it easy to explore what Drupal AI can do or even show it to customers.

With the latest Drupal AI, you can ask questions and get answers grounded in your site's content. You can audit your content against brand guidelines, translate content, classify content, build pages and React components with AI, and more. Through MCP, AI assistants can work with Drupal content from outside Drupal.

What excites me most is the foundation underneath all of this. Drupal AI turns Drupal into an AI harness: organizations can connect AI models to structured content, tools, and workflows, while keeping control through permissions, guardrails, observability, metering, and a choice of AI models.

Opening Drupal's capabilities to other software

The second part of my keynote looked at another important shift: AI assistants can give people a new way to work with Drupal.

In one demo, an editor simply asked an AI assistant to unpublish a page. They didn't need to know where to click or understand Drupal's revisions, moderation workflows, or permissions. The assistant translated their intent into action, but Drupal remained in control: it checked whether the editor was allowed to unpublish the page and applied the site's publishing rules, just as it would if they had done it by hand.

If you want to see the demo in more detail, Scott Falconer, who worked on it, recorded a behind-the-scenes walkthrough showing how to set it up yourself, what happens under the hood, and how to get involved.

That demo was built on the Tool module, which I believe is one of the most important modules for Drupal developers to watch. Drupal modules already contain thousands of useful capabilities: publishing content, managing users, processing media, changing configuration, and much more. The Tool module gives developers a standard way to expose those capabilities so AI assistants and other software can discover and use them.

Today, exposing existing capabilities as tools can still require too much code. My own album module didn't expose tools, and making its existing capabilities available to an AI assistant took about 1,000 additional lines of code.

But once those tools were available, the value became obvious. Adding MCP support has already changed how I manage the more than 10,000 photos on my site. Tasks that used to take a lot of time can now be done much faster and more accurately with an AI assistant, while Drupal still manages the content, permissions, and workflows underneath.

That experience reinforced something I wrote about in AI and the great CMS unbundling: AI can take on more of the execution work while Drupal remains the control layer. I expect more organizations will want to manage parts of their sites through AI assistants. AI can make complex tasks much faster and easier without giving up the structure, governance, and safeguards that Drupal provides.

I believe thousands of module developers will eventually want to expose their capabilities in the same way, so I've been working with Matt Glaman to make it much easier. Matt has been developing a change to the Tool API that lets developers expose existing PHP methods as tools using attributes.

The idea is simple: add PHP attributes to an existing method to describe its name, purpose, inputs and outputs. In my album module, roughly 1,000 lines of integration code became about 20 attributes. My site already uses the experimental branch, and we're working to get it merged into the Tool module proper.

And this isn't only about AI. The same tools can be called by AI assistants over MCP, by other applications over HTTP, or used to generate schemas for JavaScript components and connect Drupal modules to workflow systems like ECA, FlowDrop, and Maestro. The video below shows FlowDrop using capabilities exposed by my album module:

Talk louder about Drupal

In the last part of my keynote, I came back to Drupal's reputation gap. We can make enormous progress with Drupal, but that doesn't automatically change what people or AI agents think of it. For example, an AI coding agent I tested in June didn't even mention Drupal CMS or Site Templates when it evaluated Drupal.

Over the past few years, much of my personal focus has been on accelerating innovation in Drupal. That work is paying off, and we have real product momentum. I'm now shifting more of my attention to the other side of the equation: making sure people see what we've built, understand what has changed, and know why it matters.

So I announced the Drupal Advocacy Program, led by the Drupal Association.

Drupal already has a contribution credit system. It recognizes the people who contribute to Drupal and the organizations that support their work. For businesses, those credits also help determine visibility in the Drupal marketplace. Until now, we've been much better at recognizing technical contributions and financial support than advocacy work.

The new Drupal Advocacy Program will change that. Advocacy work can now earn contribution credit, and work that reaches people outside the existing Drupal community can earn more weight.

If we want to close Drupal's reputation gap, we can't only talk to people who already know Drupal well. We need more talks at external events, articles in broader publications, customer stories, demos, tutorials, and other work that helps people see what Drupal can do today.

Blue Drop Labs is a good example of what I mean. The day after the DriesNote, they published a post on building a website with Drupal CMS and Canvas Headless. The project itself was already live, but they quickly turned that work into a story others could learn from, with demos showing how editors and developers work with Drupal today.

That is exactly what I mean by "talking louder". There is already a lot of impressive Drupal work happening. We need to do a better job of showing it to the world.

I was a little nervous about announcing the Advocacy Program. We've wrestled with Drupal's reputation gap for a long time, and I felt we needed to do more than acknowledge it. Using contribution credit to reward advocacy was a concrete way to change the incentives, but I wasn't sure how the community would react.

It turned out to be one of the best-received announcements of the keynote. That response gave me confidence that people were ready to act on the reputation gap, not just recognize it.

You can learn how to earn Drupal advocacy credit and submit your advocacy work.

My ask is simple: talk louder about Drupal, especially to people outside our community. Drupal doesn't need hype, but we do need a better public record. We need more people showing, with real examples, what Drupal can do today.

I want to extend my gratitude to everyone who contributed to making my presentation and demos a success. A special thank you to Bálint Kléri, Christoph Breidert, Gábor Hojtsy, Lauri Timmanee, Matt Glaman, Michael Lander, Pamela Barone, Shibin Das, and the Drupal AI partners. Many others contributed indirectly to make this possible. If I've inadvertently omitted anyone, please reach out.

Drupal has always been at the core of Acquia, but for the past 5 years it was less visible in how we described ourselves. Now it's front and center again.

But that is not the main reason for the rebrand. The bigger reason for the rebrand is to help people see what Acquia has become. Our products have evolved faster than awareness of them.

The new brand leads with content instead of digital experiences, and the homepage calls Acquia an "agentic content platform" rather than a "digital experience platform".

Acquia Source is our new command center, bringing content management, digital asset management, and web governance into one workspace. Acquia AI coordinates agent work across those tools.

For agents to work safely across these tools, they need content they can trust and clear rules for using it. Somebody still has to decide what is approved, who can use it, and where it can go. I wrote about that in AI and the great CMS unbundling, and the new brand puts that idea at the center of our story.

Drupal is well suited for that job. Structured content, granular permissions, workflows, and revision history are the things agents need to work safely, and Drupal has refined them for years.

Customers can use Acquia Source CMS, our fully managed Drupal SaaS offering. For teams that want full control over their Drupal sites, we offer Acquia Cloud. Acquia Source brings sites on either platform into a shared workspace.

As you scroll the new homepage, it builds up our technology stack one layer at a time, starting from Drupal.

Acquia leaning into Drupal is also good news for Drupal itself. It helps close the gap between Drupal and its reputation. Drupal is still often seen as a CMS that requires a developer for everything, even as improvements in recent years have made it easier for marketers to build pages and manage content themselves.

So alongside the new brand, we'll be investing more in helping the Drupal community evangelize Drupal, reaching developers and marketing leaders who may not have looked at it in years. I want more people to see what Drupal has become.

The test for a good record is simple. A buyer should be able to answer three questions in about a minute: does this vendor contribute at all, how much do they contribute compared to other vendors, and do they work on the parts of the project I care about?

A good record serves both sides. Buyers get answers they can check, and vendors who contribute get credit for work that often goes unseen.

Of course, contribution does not prove that a vendor can deliver. It is one procurement factor alongside delivery capability, expertise, and price.

Vendor claims are hard to verify and compare

Say you need a vendor for your Drupal site, your Kubernetes cluster, or whatever Open Source software you use, and two firms bid. Both say they're deeply involved in the project, and both might be telling the truth by their own definition of "involved".

Without a project record, verifying those claims often means reconstructing each vendor's contribution history yourself.

The code repository seems like the obvious place to start, but even counting commits by vendor is not simple. A project has to connect individual contributors to the organizations that employed or funded their work, and those relationships can change over time.

More importantly, Open Source contribution can include documentation, support, event organization, governance work, promotion, and more. Much of that work happens outside the code repository or isn't recorded in a form a buyer can easily interpret. The data may all be public, but public is not the same as usable. A contribution record exists to close that gap.

Projects are best placed to decide which contributions matter

Drupal has tracked contribution credits since 2015, following a method I proposed in 2014 and now governed by the Drupal Association. Its system records more than code and gives credit not only to individual contributors, but also to the organizations and customers that fund their work.

Not every contribution counts the same. A contribution to Drupal Core or a strategic initiative earns more credit than one to a module that few sites use, and work on contributed projects counts for more when more sites depend on them.

Raw contribution data does not tell buyers which work matters most to the project. The project has the context to decide what advances its priorities and how different contributions should be weighted. Its record should publish those rules, link to the underlying contributions, and explain how mistakes are corrected.

In Drupal, contribution credits feed into the Drupal.org marketplace where buyers can look up agencies and compare them. While we have a strong foundation, we still have work to do to make the record easier to find, understand, and compare.

The record is the project's job, not the vendor's

A fair objection is that this puts the burden on the wrong party: if a vendor claims to contribute, the vendor should prove it, and the project shouldn't spend scarce time tracking contributions.

Suppose the two firms from earlier both send proof. Each proves its own numbers, in the measure it looks best on, and it is still not clear who has the better record. Buyers meet this problem everywhere, which is why procurement leans on third parties: auditors, certifiers, industry analysts, references.

For vendor contribution, the project is often the natural third party. The work happens inside it, so it has the data and is uniquely placed to express an opinion on the value and strategic impact of a vendor's contribution.

A contribution record is a way for a project to recognize its Makers and to say who it would like to see win bids. It also settles the question once, for every buyer, instead of every buyer auditing every bid.

A project should take on the burden when publishing the record is in its interest. Making contribution visible steers commercial work toward the vendors that sustain the project, and that work is what pays for the contribution. So the project gets more contribution, and public credit is how the project gives back to the vendors that contribute.

Projects can start with a simple record

Not every project may want or need a system as elaborate as Drupal's. How much record a project needs depends on how services around it are bought and sold: a project with hundreds of firms competing for work needs more than one with a handful of known vendors, and a project with no commercial ecosystem may not need a record at all.

For a small project, a text file in the official repository listing its recognized organizational contributors and what they worked on can be enough for a first version.

More complex ecosystems may need to categorize vendors, support searches by location, or weight different kinds of contribution. Whatever form it takes, the record has to be easy to find and quick to use.

So if you maintain an Open Source project with a commercial or institutional funding ecosystem, start publishing a contribution record and improve it over time.

If you buy services built on Open Source, ask for the project's contribution record. Decide at the start how contribution should count in your purchasing decision, then check bidder claims against the record.

Finally, if you fund Open Source, use the record to find contributors working on the parts of the project you want to support.

Where buyers and funders can consider contribution, I expect projects with clear records to see more commercial opportunities go to their maintainers than projects that rely on appeals alone.

Special thanks to Henry Poole for his contributions to this blog post, and to Sachiko Muto, Tiffany Farriss, Tim Lehnen, and Amandine Le Pape for their review.

Economists often classify goods along two dimensions. The first is excludability: how easy it is to keep someone from using something. The second is rivalry: whether one person's use leaves less for everyone else.

Combining those dimensions produces four kinds of goods.

A private good is both excludable and rival. A sandwich is a simple example: the shop can choose whether to sell it to me (excludable), but once I eat it, nobody else can (rival).

A public good is hard to exclude people from and is not used up through use. A weather forecast is a good example: once published, it is hard to prevent people from using it (non-excludable), and one person's use does not make the forecast less available to anyone else (non-rival).

A common-pool resource is also hard to exclude people from, but it is rival. Fish in the ocean are the standard example. It's hard to prevent people from fishing the ocean (non-excludable), but one person's catch leaves fewer fish for everyone else (rival).

A toll good is excludable but largely non-rival until it reaches capacity. A toll road can keep drivers out (excludable), but one more car does not reduce anyone else's access until traffic builds up (non-rival until congestion). James Buchanan also called these club goods.

The four goods in an Open Source project

People often describe Open Source as both a public good and a commons, but the terms answer different questions. A public good describes a resource's economic characteristics; a commons describes how shared resources are governed.

An ecosystem can be governed as a commons even when its parts have different economic characteristics. That is why it's useful to classify things like code, infrastructure, maintainer time, or collective reputation separately.

Open Source code itself behaves much like a public good. Making another copy does not reduce what others can use. And because Open Source licenses allow recipients to redistribute the code, restricting access becomes difficult after release.

Steven Weber goes further in The Success of Open Source, describing Open Source as anti-rival (not a dimension shown in the table). Under the right conditions, its value can grow as adoption and participation grow. More users can bring more testing, bug reports, features, documentation, promotion, and other contributions.

But the code is only one part of an Open Source project.

Many large projects are Stewarded Open Source. A foundation, company, or community operates its package registries and build systems, responds to security issues, coordinates releases, and more. Each of those activities has its own economics and can be mapped to the four types of economic goods.

A project-operated package registry or the data service behind in-product update and security notifications can behave like a toll good. The project could rate-limit access, require accounts, or reserve additional capacity and features for paying customers.

Support and consulting are private goods. A contract determines who receives the service, and an hour spent helping one customer cannot also be spent helping another.

Maintainer attention can also behave like a private good. Access to dedicated review time can be restricted (excludable), and time spent reviewing one patch cannot also be spent on another (rival).

However, that private input can produce a public good. A funder can pay a maintainer to fix a bug or review a patch, but once the improvement is released under the project's Open Source license, anyone can use and redistribute it. Economists call this the private provision of a public good.

The commercial opportunities an Open Source project generates are a common-pool resource. Customers arrive looking for help because the project has a reputation, and any provider can pursue them (non-excludable). But an engagement won by one provider is gone for the others (rival). The pool of potential customers is the ocean; a signed contract is a fish that has been caught.

What keeps that pool stocked is the project's collective reputation. It is built by many contributors, and every provider draws on it, whether they contributed or not. A provider can win engagements from the pool without helping maintain the project that produces them. Poor-quality work or unhealthy competition can weaken the reputation, and a weaker reputation means fewer customers arrive for everyone.

This is why I have argued that Open Source communities should help customers distinguish between Makers and Takers. Making contribution visible steers commercial demand toward providers that help sustain the project and the reputation that keeps customers coming.

A project-operated marketplace that lists service providers is one way to do this. Access to it can behave like a toll good: the project controls which providers it lists (excludable), while listing one more provider usually does not prevent others from participating (non-rival). Open Source gives providers rights to the code, not a right to promotion by the project. A project can therefore require providers to contribute as a condition of marketplace participation.

A funding rule for stewardship

For an Open Source project, this framework leads to two practical questions: what can it charge for, and what does it need to budget for?

Excludability shows where an Open Source project can control access and therefore where direct pricing is possible. For example, a project could charge for access to its package registry, security notification service, or provider listings in its marketplace. In each case, the project controls something separate from the released code, which remains available to everyone.

Rivalry shows what use can deplete and therefore where capacity must be budgeted. Copies of code do not run out. Bandwidth, server capacity, staff time, and maintainer attention do. A project may still choose to provide them for free, but someone always has to absorb their cost.

Together, the two dimensions suggest a simple funding model: revenue from excludable goods can pay for rival resources, while Open Source code remains a public good.

That does not mean every excludable service should be put behind a paywall. Charging everyone to use a package registry could slow adoption by making the software harder to try. It's why I previously proposed a tiered model for Open Source infrastructure: keep core services free for individuals and small projects, while asking organizations that use them at scale to help pay for what they consume.

Across the four categories, projects can look to private and toll goods for funding, protect common-pool resources from depletion, and use that funding to pay for the work that produces public goods.

Projects that do not make those arrangements explicit will continue to depend on invisible subsidies for infrastructure and maintainer work.

Keeping software relevant and dependable requires people to write code, review contributions, prepare releases, investigate security reports, operate infrastructure, write documentation, answer questions, and support upgrades and migrations. Someone always bears those costs.

A proprietary vendor can tie access to payment: every license or subscription sold helps fund developers, security work, infrastructure, and releases.

Open Source breaks the link between access and payment. Anyone can redistribute the software at any price, including zero. Payment is therefore not a condition of using or redistributing it, and those rights do not themselves provide a durable mechanism for funding production and maintenance.

But separating payment from access does not make the costs disappear. Costs are distributed across maintainers, employers, foundations, sponsors, and users. A maintainer may volunteer their time. An employer may pay a developer to contribute. A foundation may operate infrastructure.

Because these costs are distributed rather than collected through a single transaction, they are harder to see and harder to fund.

Technical choices often shape where those costs fall. That allocation is not always deliberate; it can emerge slowly from decisions that were individually reasonable and become visible only years later.

Drupal's update service recently gave me a good example. Drupal sites periodically contact updates.drupal.org to ask whether new versions of Drupal or any installed add-ons are available. Drupal calls these add-ons "contributed projects", such as modules and themes maintained by members of the community.

The current design sends one request for Drupal itself and one for every contributed project installed on the site. A site with 100 contributed projects therefore makes 101 requests each time it checks for updates, by default, once a day.

There were good reasons for that design. Each project's release history could be stored as a static file and served repeatedly without rebuilding it for every request. The design was straightforward, and it worked.

But Drupal grew. Today, updates.drupal.org serves nearly a billion requests a month. The file containing Drupal Core's release history is roughly half a megabyte by itself. Based on the number of requests for that file, I estimate that Drupal Core update checks alone may account for roughly 50 to 75 TB of data transfer each month. Traffic for contributed projects comes on top of that.

No one chose to make updates.drupal.org transfer tens of terabytes of release data each month. That scale emerged gradually as Drupal grew, from a design that had been reasonable when the ecosystem was smaller.

Part of the challenge is that, in Open Source, the people who benefit, the people who decide, and the people who bear the costs are often different and may have no formal obligations to one another.

Site owners benefit from reliable update notifications, usually without paying the Drupal Association for them. Drupal Association staff operate the update service, while the Association bears its traffic and infrastructure costs. But the code that determines how sites make those requests lives in Drupal Core, where changes require the involvement of Core committers. The Core committers do not report to the Drupal Association, so the Association cannot change that behavior on its own.

In practice, Drupal Association staff and Core committers collaborate closely. That collaboration is important because decision-making authority and cost-bearing sit with different groups.

The people bearing material costs need a way to make those costs visible and influence the decision, even if they do not control it.

This example shows why every Open Source architecture is also a cost-allocation system. Good governance considers that allocation up front, monitors its effects over time, and revisits it when it becomes unsustainable.

Understanding an Open Source system therefore requires more than understanding its code or license. We also need to understand who benefits, who decides, and who bears the costs as the system grows. Once those relationships are visible, a community can decide whether the allocation is sustainable or whether the architecture should change.

I looked at how other content management systems identify related posts: most use shared tags, backlinks, manual curation, or embeddings. I chose embeddings, which compare the meaning of each post, because they can uncover connections without shared tags, existing links, or manual curation.

Embeddings turn meaning into numbers

An embedding model reads text and returns a vector: a long list of numbers. The model I use, bge-base-en-v1.5 from the Beijing Academy of Artificial Intelligence (BAAI), returns 768 numbers for each post.

For one of my posts, the first handful of those coordinates looks something like this:

[ 0.021, -0.045, 0.038, -0.012, 0.007, ..., 0.019 ]

You can think of those 768 numbers as coordinates in a high-dimensional meaning space, where each dimension captures some pattern the model learned from text.

Conceptually, it is a bit like tagging each blog post with hundreds of auto-generated tags, except that these tags are unnamed (they are just numbers) and distributed (meaning is spread across all of them). Together, the 768 numbers place the post near other posts with similar meaning.

This is what lets two posts match even when they use different words. During training, the model learns that certain words and phrases appear in similar contexts or play similar roles, so it places them near each other in the space. It does not need "car" and "automobile" to share any letters to learn that they are used in related ways.

Raw cosine similarity makes everything look related

Once every post has an embedding vector, the next question is how to compare them. This is where I had to dust off a little math. Fortunately, it turned out to be mostly high-school math: averages, angles, and multiplication.

The standard way to compare two vectors is cosine similarity. Imagine each vector as an arrow pointing away from the origin. Cosine similarity measures the angle between two of these arrows and then takes the cosine of that angle, which is where the name comes from.

Two arrows pointing in nearly the same direction form a small angle, and the cosine of a small angle is close to 1, meaning the posts are related. As the arrows spread apart, the cosine falls: at a right angle it is 0, and for arrows pointing in opposite directions it drops to -1, so unrelated posts score closer to 0 or even negative.

In practice, these raw cosine values can be misleading, because embedding models rarely spread their vectors evenly in every direction. They tend to pack most vectors into a narrow cone, a property called anisotropy. It means that the cosine similarities tend to cluster in a narrow band.

On my blog, the raw cosine similarity between two randomly chosen posts is almost always between 0.5 and 0.75, with a median of 0.64. The practical effect is that almost any two posts look somewhat similar even if they are not.

Mean-centering reveals what makes each post distinct

Anisotropy has several known fixes. The easiest is mean-centering, which is what I use and what the rest of this section explains.

Other solutions include All-but-the-top, which removes the average and the next few strongest directions. Whitening stretches the space so every direction carries equal weight (the name comes from white noise).

With mean-centering you simply compute the average vector across all posts and subtract it from every post's vector. Subtracting the average vector from each post removes what all posts have in common; what remains is what makes each post distinct.

A modern model like bge-base-en-v1.5 already suffers less from anisotropy than older or simpler encoders: it is trained with contrastive learning, which pushes unrelated texts apart, and version 1.5 was tuned specifically to spread out its similarity scores. That said, centering still made the scores much more useful on my corpus.

An example might help. Imagine three posts with only two numbers each instead of 768:

A = (0.90, 0.10)
B = (0.85, 0.80)
C = (0.80, 0.75)

At first glance, all three posts might look somewhat similar. In every post the first number is high and close to the others (0.90, 0.85 and 0.80). A number that barely changes from post to post tells you little about how they differ, so that first number is not very useful.

The average (mean) of the three vectors is:

mean = (0.85, 0.55)

Now subtract that average from each post:

A = ( 0.05, -0.45)
B = ( 0.00,  0.25)
C = (-0.05,  0.20)

Now the picture is already clearer. B and C both have a positive second number, so they point in roughly the same direction; A's second number is negative, so it points somewhere else.

Before centering, everything looked similar. After centering, the comparison focuses on what is different from the average.

Normalization reduces comparison to a dot product

After centering, each vector has a length as well as a direction. Length says how far a post sits from the average, and direction says in what way it differs.

I want to rank posts by what they are about, not by how unusual they are, so only the direction matters. Hence, we normalize each vector by dividing it by its own length, which scales it to length 1 and moves it onto the unit circle (or, in 768 dimensions, the unit sphere), leaving only its direction.

It also makes the comparison cheaper. Cosine similarity is normally the dot product divided by the product of the two vectors' lengths. If both vectors have length 1, that denominator is 1 × 1 = 1, so the expression reduces to the dot product alone: multiply the two lists number by number, then add the results.

Using the same example, the centered vectors for B and C are:

B = ( 0.00, 0.25)
C = (-0.05, 0.20)

First, normalize each vector to length 1. A vector's length is the square root of the sum of its squared numbers (good old Pythagoras, only with more numbers). B has length √(0.00² + 0.25²) = 0.25, while C has length √((-0.05)² + 0.20²) ≈ 0.206, so dividing each vector by its own length gives:

B ≈ ( 0.00, 1.00)
C ≈ (-0.24, 0.97)

Then take the dot product:

(0.00 × -0.24) + (1.00 × 0.97) = 0.97

That is a strong match: the closer the score is to 1, the more the two posts point in the same direction. B and C are nearly aligned.

A, after normalization, points mostly downward. Next to B:

A ≈ ( 0.11, -0.99)
B ≈ ( 0.00,  1.00)

Multiplying them the same way:

(0.11 × 0.00) + (-0.99 × 1.00) = -0.99

That is not a match at all.

The PHP code is shorter than the explanation

The production code does the same arithmetic, just with 768 numbers per post instead of two:

public static function center(array $raw): array {
  if ($raw === []) {
    return [];
  }
  $mean = array_fill(0, count(reset($raw)), 0.0);
  foreach ($raw as $vector) {
    foreach ($vector as $i => $value) {
      $mean[$i] += $value;
    }
  }
  $count = count($raw);
  foreach ($mean as $i => $sum) {
    $mean[$i] = $sum / $count;
  }
  $centered = [];
  foreach ($raw as $nid => $vector) {
    $norm = 0.0;
    foreach ($vector as $i => $value) {
      $vector[$i] = $value - $mean[$i];
      $norm += $vector[$i] * $vector[$i];
    }
    // A vector sitting exactly on the mean centers to zero; fall back to 1.0
    // so the division below never hits a zero norm.
    $norm = sqrt($norm) ?: 1.0;
    foreach ($vector as $i => $value) {
      $vector[$i] = $value / $norm;
    }
    $centered[$nid] = $vector;
  }
  return $centered;
}

public static function topMatches(array $source, array $pool, int $self): array {
  $scores = [];
  foreach ($pool as $nid => $vector) {
    if ($nid === $self) {
      continue;
    }
    $similarity = 0.0;
    foreach ($source as $i => $value) {
      $similarity += $value * $vector[$i];
    }
    $scores[$nid] = $similarity;
  }
  arsort($scores);
  return array_keys(array_slice($scores, 0, 3, TRUE));
}

While my explanation was long, both PHP methods are relatively short. In center(), each vector has the corpus mean subtracted, then is divided by its own length. In topMatches(), I calculate the cosine similarity between one post and every other post, then keep the three highest.

You might expect a vector database to replace all of this. It would replace some of it: storing a vector and asking for the closest three would remove topMatches(), but it would not remove center(). Centering is optional, but it meaningfully improved my results.

A vector database likely makes centering harder. Today I store raw vectors and subtract the average when I compare them, so a new post does not change anything I have stored. A vector database would search what I stored, so the subtraction would have to happen before storing. I'd have to update all stored vectors for every new post or every edit, which feels more complex. Maybe vector databases have a good answer for that; I have not looked.

One-time embeddings, occasional ranking

You might wonder how expensive it is to generate these embeddings and compare all these vectors. It turns out to be fast and cheap.

There are two kinds of work, and they happen at different times. Generating an embedding calls an AI model, but happens only once after a post is created or edited. Ranking uses ordinary PHP arithmetic and happens occasionally, when Drupal rebuilds a page's cached related-post list.

I run the model on Cloudflare Workers AI. To generate an embedding, my server makes an HTTPS call that passes the post's text to Cloudflare, which runs the model and returns the 768-number vector. That round trip takes about 250ms. It happens on the first view after a post is created or edited, and the vector is then cached. The model is deterministic, so the same text always produces the same 768 numbers.

Cloudflare bills Workers AI usage in units it calls Neurons and includes 10,000 free each day. Embedding my full archive of roughly 1,500 posts used roughly 4,000 Neurons, and a new post costs about three. Embedding my blog is basically free.

Calculating the related posts never calls the AI model. It all happens in Drupal, my website's content management system. When Drupal needs to build one of the related posts lists, it loads all the stored vectors, centers them, and scores the current post against all the others: roughly 1,500 dot products, each over 768 numbers. This takes around 250ms on my site. After a list has been built, it is cached.

In other words, my website never loads model weights; it just stores the 768 numbers that come back. The machine-learning compute lives at Cloudflare's edge, and my server stays a plain PHP application. None of this needs a vector database or a machine-learning framework: one HTTP call generates the embedding, a key-value store caches it, and a few dozen lines of arithmetic choose the related posts.

Tags are too blunt, backlinks only capture the links I remembered to make, and manual curation does not scale. All three need me to notice the connection first. Using embeddings might sound a bit scary, but they turned out to be easy to implement, fully automated, and able to surface posts I would never have thought to link.

I have lived with a version of that question longer than most.

I released Drupal for free more than twenty-five years ago, and later co-founded Acquia, which has grown into a large enterprise software company built around Drupal.

Granted, Drupal is free in a different way than AI-generated applications are free, but I'm not sure that changes the basic question of how to build a successful business around either one.

Open Source made code abundant by giving people broad rights to use, modify, and redistribute it. AI is lowering the cost of producing code. One lets you copy the software; the other makes it cheaper to recreate software.

Free code changes what customers pay for

Because anyone could use Drupal for free, Acquia could never build a durable business around access to the code. From the start, we had to make money another way.

We built that business around helping enterprises build, run, and manage Drupal applications throughout their lifecycle. That includes hosting, but goes well beyond it: the tools and services needed to develop, deploy, secure, scale, monitor, and improve applications in production.

Proprietary SaaS typically bundles access to the application with the hosting and operations required to run it. With Open Source, organizations can run the software themselves or choose who hosts and operates it.

As AI makes applications cheaper to recreate, the traditional SaaS bundle of software and operations comes under pressure. Customers may become less willing to pay for access to application functionality without becoming any less willing to pay to run and manage applications in production. For Open Source businesses those economics are not new.

Dependability becomes the product

Software can be free, or nearly free, without becoming cheap to depend on. The more people and organizations depend on a system, the more of its value comes from operating it securely, reliably, and at scale.

Once people depend on an application, the cost of its failure has little to do with how much it cost to build. An application that costs $1,000 to build can still cause a $10 million failure.

As AI makes enterprise applications easier to create, adapt, and integrate, they still have to be deployed, secured, scaled, monitored, and run reliably over time. As software cost comes down, dependability becomes a differentiator.

Linux is abundant; dependable cloud infrastructure is a service worth paying for. Drupal is abundant; dependable digital experience infrastructure is a service worth paying for.

Acquia has lived with those economics for nearly 20 years. Drupal made the code abundant, so we built our business around helping organizations build, run, and improve what they created with it. As AI makes code cheaper to generate, that business model may start to look a lot less unusual.

Either way, more software companies will have to answer the same question: if code and capabilities are abundant, what are customers really paying you for?

So far, no agent has found my search on its own. The API Catalog has been a published IETF standard for over a year but I found no evidence that either OpenAI or Anthropic checks for it. ARD is newer, still a v0.9 draft, and I found no evidence that OpenAI or Anthropic supports it either.

In the meantime, what does work is a custom Agent Skill that points my AI assistants to the API Catalog, which leads them to my OpenAPI description and from there to the search itself. If and when agents adopt one or more of these discovery standards, I might be able to drop the skill and have it all work automagically.

Until last week, I had decided Model Context Protocol (MCP) was not worth implementing for my search API endpoint. It required an initialization handshake and could involve protocol-level sessions. My search doesn't need either: every query is stateless and anonymous. MCP felt like overkill for my simple use case.

The 2026-07-28 revision changed my mind because both the protocol-level session and the initialization handshake are gone. Every request can now be self-contained, which means that, for a service like mine, an MCP server is basically a POST route that returns JSON.

So I went ahead and implemented MCP support for my search endpoint. The whole thing came to one route and three small RPC methods: fewer than 150 lines of code, excluding tests.

You can call it from any terminal

In my testing, adding my site as a custom MCP connector to Claude Desktop, Claude Code, or ChatGPT still fails. These clients don't support the new protocol yet, which is understandable because it is only a week old. Once they catch up, anyone will be able to add dri.es as a connector, not just me.

Until then, an easy way to talk to my site with an MCP client is Simon Willison's mcp-explorer. You can run it with uvx, which comes with uv:

uvx mcp-explorer list https://dri.es/mcp
uvx mcp-explorer call https://dri.es/mcp find_posts -a query "open source"

The first command prints each tool's name, description, and arguments. The second runs a search across my posts and returns up to twenty results.

Alternatively, you can use the raw protocol by running this curl command from a terminal:

curl -s https://dri.es/mcp \
  -H "Content-Type: application/json" \
  -H "MCP-Protocol-Version: 2026-07-28" \
  -H "Mcp-Method: tools/call" \
  -H "Mcp-Name: find_posts" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"find_posts","arguments":{"query":"open source"},"_meta":{"io.modelcontextprotocol/protocolVersion":"2026-07-28"}}}' \
  | jq .result.structuredContent

Discovery and invocation are separate layers

Having implemented support for three new standards, the useful thing I learned is that they are not alternatives.

ARD handles discovery: it gives registries a standard way to index and search for services like mine. OpenAPI and MCP handle invocation by defining how agents can call and use those services.

So the choice is not ARD or MCP. It is ARD plus OpenAPI, or ARD plus MCP.

For an anonymous, read-only API like mine, I prefer OpenAPI. It was easier to implement and anything that can make an HTTP request can use it.

MCP becomes more attractive when you have services that involve multi-step interactions, authentication, or explicit application state.

Ultimately, agent and crawler adoption will decide. Time will tell, but my money is on ARD and MCP right now.