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 search -a q "open source"

The first command prints the 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: search" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"search","arguments":{"q":"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.

Those choices determine whether harm is possible at all. So when harm occurs, responsibility should fall on those who controlled the relevant choices. That responsibility may be shared: model developers control training and release, product builders control permissions and deployment, and users control deliberate misuse.

Responsibility should follow meaningful control

That principle is missing from much of the debate over open-weight AI models, which often treats the decision to release a model as the only one that counts.

Axios recently reported that United States officials had considered measures that could restrict American companies from using Chinese open-weight models. Open-weight models make their trained parameters available for others to download, modify, and run on their own infrastructure, without going through the company that built them.

More than 230 companies and organizations have since signed an industry letter defending open weights. After critics accused Anthropic of supporting a ban on open-weight models, Anthropic CEO Dario Amodei published a statement denying that position. He described open-weight models that do not have dangerous capabilities as a public good and supported mandatory safety testing for sufficiently capable models, open or closed.

The disagreement is less about whether open weights can create risk than about when those risks justify restricting a release, and whether restrictions would improve safety or mainly concentrate power in the largest AI labs.

I am firmly in the open-weights camp. I have run and compared open-weight models, argued that digital sovereignty depends on who controls software, not where it comes from, and believe organizations should control their infrastructure and data instead of depending on a handful of providers.

I also believe consequential algorithms need oversight. More than a decade ago, I argued that we would eventually need something like an FDA for software. The harder question is where responsibility for that oversight should lie.

Open-weight models unbundle control

With hosted, closed-weight models from providers such as Anthropic and OpenAI, the provider typically keeps the weights private, controls how customers access the model, and decides when to update the hosted service.

Open weights can separate those roles. One organization creates and releases the model. A repository such as Hugging Face hosts and distributes the weights. Another team might fine-tune them. A product builder incorporates the model into a product and connects it to data, tools, and users.

Each team controls something different. Because open weights unbundle control, it becomes harder to say who is responsible when harm occurs.

A model developer controls the training process, capability testing, documentation, and release decisions. A repository controls what information it displays about a model's origin, which security checks it performs on uploaded files, and which access restrictions it provides or enforces. A product builder controls what data and tools the resulting system can reach, which actions require human approval, and what gets logged.

Control is not the only thing that matters, but it shows who could still have changed the outcome. When harm involves AI, several actors may bear responsibility for the same incident because each controlled a different opportunity to prevent it.

Open Source shows how responsibility follows control

Like open-weight models, Drupal's Open Source code can be copied and changed without asking anyone's permission. A site owner could use it to spread misinformation or operate a fraudulent website. The site owner controls the content and operation of the site and is responsible for those choices. The Drupal project is not responsible merely because someone used its code.

But the Drupal project controls other decisions. When someone privately reports a security vulnerability, the Drupal Security Team follows a coordinated disclosure policy. It keeps the issue private while a fix is prepared. Once a security release is available, the team publishes an advisory and tells site owners to upgrade. The timing of that disclosure can give site owners a fair chance to protect themselves.

The same distinction applies to AI. Responsibility should follow the decisions each actor controls.

Products turn capability into authority

A model generates outputs. An agent is a software system that uses a model to work toward a goal, often by calling tools and taking actions. The people who build and configure the agent decide what it can access, which actions it can take, and when it needs a person's approval.

In a coding agent such as Claude Code, a model can generate a database command. Whether that command can run depends on the tools and permissions the agent provides, as well as the access allowed by the computer, network, and database.

A content management agent can propose deleting an article. The content management system (CMS) determines whether the agent has permission to delete it, whether the deletion is reversible, and whether the action is recorded.

Permissions, isolation, audit logs, rate limits, human approval, and rollback are not merely engineering details. They determine who has control at the point where harm can still be prevented. That is why AI governance is becoming an essential part of product architecture.

Regulate AI at each point of control

Deciding who should answer after harm is easier, even when the answer is not obvious. The harder question is what government should require before any harm has happened.

If control and responsibility are distributed across several actors, government rules should be distributed across them too. This is not a new idea. We already regulate many technologies this way.

More than a decade ago, when I argued for something like an FDA for software, I had drug approval in mind. I no longer think that is the right model. The FDA approves a drug for one or more intended uses, while a general-purpose model may be used for many different purposes.

Cars are a better comparison. The government sets safety standards, and manufacturers certify that their vehicles meet them. Separately, drivers must pass a test defined by the government before they are licensed to drive.

The layers extend beyond cars and drivers. States set legal blood-alcohol limits for drivers and require bars to have licenses they can lose. In many states, a bar can also be held liable for serving a visibly intoxicated person who later causes harm.

Each rule targets the actor who controls a particular decision. Together, they reduce risk for everyone. I would take the same layered approach to AI.

Blocking a model's release is a much stronger step, and one that should rarely be used. For an open-weight model, that means preventing the developer from publishing the weights. For a closed model, it could mean preventing the provider from offering access.

I would support that only when safeguards in products and rules governing their use could not prevent a serious danger in time. The two-part test below applies only to this exceptional step, not to AI regulation in general.

Require extraordinary evidence to block a release

The strongest argument for restricting an open-weight release is that it is effectively irreversible. Once the weights are public, the developer cannot withdraw every copy, monitor how the model is used, or ensure that its safeguards remain in place.

If a model made catastrophic harm much easier, its release could be the last moment anyone had meaningful control. By catastrophic, I mean mass-casualty or comparably systemic harm, not ordinary product failure, fraud, or abuse.

As of July 2026, I have not seen public evidence that an open-weight model has crossed this threshold. That said, I believe it is just a matter of time, which is why I still think meaningful regulation is coming.

Before blocking a model's release, a government should have clear evidence that the answer to both questions is yes:

1. Would releasing this model make catastrophic harm much easier? Compare it with closed models and other tools people can already access.

2. Would blocking its release meaningfully reduce that danger? A restriction should not merely shift access to another country or distribution channel.

Default to openness with distributed responsibility

So where do I land today? I would default to allowing publication and place obligations where control already exists: on model creators for testing and release decisions, on distributors for provenance and file integrity, on product builders for permissions and deployment, and on users for deliberate misuse.

This approach also protects competition. A regulatory regime that only the largest labs can satisfy could protect them from competition without necessarily making anyone safer. It could also push organizations toward depending on a handful of providers for infrastructure they cannot inspect.

Open weights do not eliminate control. They distribute it, making it harder to say who is responsible when harm occurs. Regulation should follow that structure: place obligations on each actor at the point where harm can still be prevented, and block publication only when release would make catastrophic harm substantially easier and a restriction would materially reduce the danger.

Last week, I joined the Drupal AI Learners Club to discuss several experiments I had already published. Angie Byron started the club and runs it with co-organizer Amber Himes Matz. It gives people in the Drupal community a place to show how they are using AI and talk honestly about what works and what does not.

I spent an hour walking through some of my AI experiments, starting with Drupal Digests, a tool that uses AI to summarize key developments across Drupal Core, Drupal CMS, Drupal Canvas, and the Drupal AI initiative.

Drupal Digests led to another experiment: AI-generated Rector rules. When a Drupal Core change deprecates an API, Drupal Digests analyzes the issue and code changes and generates a rule that can automate the corresponding upgrade in other Drupal projects.

I also showed my API Catalog that helps AI agents discover my website's search API.

These are only some of my AI experiments. Most begin as tools I build for myself, and many never go any further. When one seems useful beyond my own work, I publish it so others can benefit from it.

Once a tool is public, we can see whether people use it and want to help improve it. If they do, it may eventually become a proper community project. If not, that is useful to know too.

The recording goes into more detail, with demonstrations of the tools and questions from the group. You can watch it below.

What ARD adds to yesterday's API catalog is discovery. If an agent has never heard of you, it does not know to look for your API catalog. Ask an agent what people have written about the future of Drupal, for example, and it will probably search Google. It may not think to check dri.es or drupal.org directly.

The web solved discovery decades ago. Search engines find the right site, so you do not have to know where the answer lives.

ARD brings search-engine-style discovery to AI agents. ARD registries crawl the web for catalogs published by sites and add their resources to a searchable index. An agent can then ask a registry a plain-language question, such as "Who can answer questions about the future of Drupal?". The registry returns a ranked list of relevant resources, perhaps pointing the agent to my site's search API.

You opt in by publishing a manifest at /.well-known/ai-catalog.json. Here is what my mine currently returns:

{
  "specVersion": "1.0",
  "host": {
    "displayName": "Dries Buytaert"
  },
  "entries": [
    {
      "identifier": "urn:air:dri.es:search",
      "displayName": "Site search",
      "type": "application/openapi+json",
      "url": "https://dri.es/openapi.json",
      "description": "Full-text search across the site's content, ranked by relevance.",
      "representativeQueries": [
        "Find posts about the future of Drupal",
        "What has been written about open source sustainability?",
        "Find writing about digital sovereignty",
        "How is AI changing how we build websites?",
        "Search Dries Buytaert's blog and notes"
      ]
    }
  ]
}

Each entry describes a resource an agent can use. ARD deliberately defines "resource" broadly: it can be an API, an MCP server, another agent, a skill, or even a nested catalog containing more resources.

My site offers just one resource: a simple search API. The whole thing took less than an hour to implement because the ARD entry simply points to the existing OpenAPI document, https://dri.es/openapi.json, that I wrote about yesterday. In other words, it makes the same API description available through a second discovery mechanism.

The representativeQueries field is the interesting part. It lists example questions registries use to match an agent's intent. Mine are first guesses that I will revise once I can see how they get used.

Of the eleven companies listed as contributors, Hugging Face is the only one whose AI catalog I could find on its primary domain. It also runs an early registry. So I queried Hugging Face's registry. It responded correctly using the protocol defined by the specification, but for my queries, it returned only skills hosted by Hugging Face.

Broad adoption will depend on whether major agents begin searching ARD registries. Microsoft, Google, and GitHub are members of the working group, but OpenAI and Anthropic are not. Google has said its Agent Platform will connect to ARD registries in the coming months, but it remains to be seen how widely the specification will be adopted.

Does my blog need this? Probably not. Other sites have more to gain. An online store could announce its product search and checkout APIs, a restaurant its reservation system, and a city its appointment system for renewing a permit.

Many of these sites run on a content management system. A CMS that made its capabilities discoverable through ARD by default could therefore be interesting. Experiments like this help me understand whether Drupal should be that CMS.

At the same time, the web is gaining a new audience. In addition to people visiting pages, AI agents increasingly access a site's knowledge and tools directly.

That combination led me to add support for /.well-known/api-catalog to my site. A request to https://dri.es/.well-known/api-catalog currently returns:

{
  "linkset": [
    {
      "anchor": "https://dri.es/search/json",
      "service-desc": [
        {
          "href": "https://dri.es/openapi.json",
          "type": "application/openapi+json"
        }
      ]
    }
  ]
}

RFC 9727, an IETF Proposed Standard, defines /.well-known/api-catalog as a predictable location for discovering a site's public APIs.

The catalog is a small JSON document written in the Linkset format. It advertises my search endpoint and, in turn, links to an OpenAPI document that tells software how to use it.

The JSON endpoint at /search/json predates the catalog and powers my site's search. However, it was not documented or easy for software to discover. The catalog now makes it explicit.

The OpenAPI document at https://dri.es/openapi.json tells AI agents exactly how to call the endpoint and interpret the results. It removes the guesswork, reducing the time and tokens agents would otherwise spend figuring out how the API works.

In short, the API catalog announces that my search API exists, while the OpenAPI document explains how to use it. An agent can start with just my domain, check /.well-known/api-catalog, follow the link to the OpenAPI document, and learn how to search dri.es directly.

The feature has been live for a few months, but I am only now writing about it. In the meantime, I have logged every request to /.well-known/api-catalog and /openapi.json. The result so far: zero AI agents have used it.

I found the same problem when I analyzed llms.txt usage: the AI crawlers it was meant for never use it, so I never bothered implementing it.

Unlike llms.txt, the API catalog solves a problem I have, and I do not need to wait for industry adoption. I recently created an Agent Skill, a SKILL.md file that directs my agents to check the catalog and use my site's search API whenever they need information from dri.es.

My agents now search dri.es directly and find posts that Google misses. And if any AI agent adopts API catalog discovery, my site is ready.

Some of these sites will move to Acquia Cloud, our Drupal PaaS, while others will move to Acquia Source, our Drupal SaaS. Drupal CMS played an important role in these decisions by making Drupal more approachable to marketers and site builders.

Why are different organizations making the same choice? One key reason is the cost of CMS fragmentation.

A few months ago, a CMO told me that her team had purchased a new digital asset management system (DAM). The estimate to connect it to the organization's websites came back at nearly $100,000 and three months of work.

Why so much? The organization ran three CMS platforms: Drupal, WordPress, and Contentful. The DAM had to be integrated with all three. That meant not only three integrations, but also three sets of expertise, three rollout plans, and three ongoing maintenance responsibilities. One new capability had become three separate projects.

Organizations are under pressure to move faster and reduce costs. CMS fragmentation creates a recurring tax through duplicated integrations, security practices, governance policies, infrastructure, technical expertise, and more. It also fragments attention and makes it harder to share improvements across teams and websites.

Organizations pay that tax every day through higher operating costs and slower execution, not only when they introduce new capabilities. When it consistently slows their ability to improve digital experiences, it can become a competitive disadvantage.

Some of this duplication can be reduced by standardizing hosting and portfolio governance across multiple CMS platforms. That is valuable, but it addresses only one layer of the problem. Each CMS still has its own extension model, editorial experience, security considerations, and required expertise.

This fragmentation usually happens for understandable reasons. Teams often make technology decisions independently, and different sites can have genuinely different requirements.

A marketing team may need to launch a campaign site in days without involving developers, making SaaS solutions attractive. A team responsible for a high-traffic enterprise application with custom integrations may need the flexibility and control of an Open Source solution running in a PaaS environment.

Each decision can make sense for the individual project while creating significant duplication across the organization.

More than 15 years ago, I argued in a post about Acquia's product strategy that organizations should standardize on a common CMS while choosing the right operating model for each site.

Today, the case is even stronger. Websites depend on more integrations, digital experiences are more complex, and AI is becoming another shared capability that organizations need to deploy across their portfolios. With multiple CMS platforms, every new capability becomes harder and more expensive to deploy safely.

Standardizing on a single CMS lets teams reuse more of their design systems, security practices, integrations, and expertise across sites. Marketers get a more consistent way to create and manage content, while developers spend less time implementing the same capabilities on unrelated platforms.

But standardizing on Drupal does not mean forcing every site into the same architecture or operating model. Organizations can share a common CMS foundation while choosing a different balance of convenience and control for each site.

That is where Acquia Source and Acquia Cloud fit together.

Acquia Source provides the SaaS operating model. It is designed for teams that value speed and simplicity. Acquia manages the underlying platform, while marketers and site builders customize experiences through the user interface, reusable components, and supported integrations. Developers can extend sites through custom components, APIs, webhooks, and other supported tools without managing the Drupal codebase or installing arbitrary modules.

Acquia Cloud provides the PaaS operating model. It is designed for sites that need deeper customization and more developer control. Teams can build custom Drupal modules, use contributed modules, manage code through Git, run CI/CD pipelines, and integrate Drupal more deeply with other systems.

Both are built on Drupal. This gives organizations a shared foundation for skills, content practices, design systems, security, and integrations, while allowing each site to choose the right balance of speed, simplicity, flexibility, and control.

A site can begin on Acquia Source when speed and simplicity matter most. If its requirements later grow to include custom modules, deeper integrations, or more developer control, the organization can export its source code, database, and files and move to Acquia Cloud or another Drupal environment without adopting a different CMS.

I have been calling this "Open SaaS": the convenience of SaaS combined with the ownership and portability of Open Source. Organizations can choose a different operating model without leaving Drupal or surrendering control of their sites.

When organizations standardize this way, the economics change dramatically. We have helped some customers save millions of dollars each year by reusing shared capabilities instead of rebuilding them for different platforms.

The goal is not to operate every website in the same way. A campaign site and a mission-critical application require different levels of speed, flexibility, and control, but they do not need unrelated CMS platforms.

The goal is to create operating leverage across an organization's digital portfolio. Each site can use the operating model that fits its needs, while teams reuse investments in content, design, integrations, security, and expertise.

Then, when the organization adds a DAM, a personalization engine, an analytics platform, or an AI capability, teams can build on shared work rather than start over for each CMS. The result is faster execution, greater returns on digital investments, lower costs, and less risk.

One CMS foundation with multiple operating models makes that possible.

This post is for that same reader, with a new map spread across the table: New Hampshire's Presidential Range.

My friend Chris and I just spent four days hiking through the Presidentials, a rugged chain of peaks named mostly after American presidents.

The classic Presidential Traverse covers roughly nineteen to twenty-three miles (31 to 37 kilometers) and involves about nine thousand feet (2,700 meters) of climbing, depending on the route and which summits you include.

We traveled from hut to hut rather than carrying a tent. Our four-day itinerary included two full days on the trail, with shorter days at the beginning and end so we could drive to and from the mountains.

On paper, the distance and elevation gain look manageable. The numbers didn't capture the effort. Much of our route followed the Appalachian Trail across loose rock and exposed ridgelines, where the weather can turn quickly.

The thru-hikers we met called the Presidentials one of their favorite sections and one of the hardest. A mile here can feel like two or three on an easier trail.

Unlike the Pemi Loop, this was a point-to-point hike. We traveled south to north, beginning near Crawford Notch and finishing at the Appalachia trailhead in Randolph.

Because the trailheads are about forty minutes apart by car, we left ours at the finish and arranged a ride to the start. Four days later, when we emerged from the woods and found the car waiting for us, it felt like a small miracle.

Day 1: Up to Mizpah Spring Hut

Our first day was short, which suited us because we had driven up from Boston and did not start hiking until two in the afternoon. From the parking lot, you climb and keep climbing until eventually there is a hut.

On the way up, we passed a steady stream of hikers heading down, all of them looking pleased to be traveling in that direction.

My left quad started complaining almost immediately. My pack was noticeably heavier than Chris', thanks in part to the unreasonable number of snacks I had brought.

We reached Mizpah Spring Hut a little more than two hours later. If a short afternoon hike could leave my quad complaining, the next two days were going to be much harder.

There was nothing to do about any of it but eat and sleep, and the hut is built for exactly that. The accommodations are rustic: no showers, no heat, and no electricity for guests. What you get is a bunk, cold well water, composting toilets, a pillow, and several wool blankets. Guests are encouraged to bring a sleeping bag or liner, so we did.

Dinner improved my outlook. The portions were absurdly generous, and the pulled pork was some of the best I had ever eaten, although two hours of climbing may deserve some of the credit.

After dinner we played chess, and I beat Chris three times in a row. To keep it interesting, I removed my own queen as a handicap and beat him anyway. I mention this only because he will read this post.

The huts pack you into bunkrooms with anywhere from six to a dozen strangers, and between Chris snoring and the general symphony of a shared room, I didn't sleep very well. The thin mattress left my shoulder and hip aching, and at one point my arm went numb. That is simply part of hut life, and it still beats sleeping in a tent.

Day 2: Pierce, Eisenhower, and the roof of the Northeast

Day two took us from Mizpah Spring Hut to Lakes of the Clouds Hut, following the high ridge of the Southern Presidentials. It was our first full day on the trail and our first sustained stretch above treeline.

We climbed Mount Pierce (4,310 ft) first, then continued toward the broad dome of Mount Eisenhower (4,780 ft). As we gained elevation, the trees thinned, shrank, and finally gave way to open rock. The trail rose into the wind, with the mountains unfolding around us in every direction.

Between Eisenhower and our destination, we crossed Mount Franklin, which looks like a summit and feels like a summit but does not officially count as one.

By early afternoon, we reached Lakes of the Clouds, the highest and best-known of the Appalachian Mountain Club's huts. We dropped our packs, claimed our bunks, and set out for the summit of Mount Washington (6,288 ft). The climb added two and a half hours to an already long day, but with the summit just above us, we kept going.

Mount Washington bills itself as the home of the world's worst weather. In 1934, observers at the summit recorded a wind gust of 231 miles per hour, a world record that stood until 1996. It remains the strongest gust ever measured at a staffed weather station. People die on and around Mount Washington nearly every year, often after the weather turns faster than they expect. We, somehow, got sunshine and crystal-clear air, with views that stretched for more than a hundred miles.

The weather spared us, but the climbing did not. Three four-thousand-footers in one day left their mark. By evening, my hiking shirt had grown salt rings from all the sweating. It was impressive, disgusting, and, with no showers at the huts, a problem for another day.

At sunset, the mountains faded layer upon layer, from blue to gray, until the last ridges disappeared. Chris and I stood and watched, tired and happy, forgetting about our knees.

The bunkroom brought me quickly back to earth. The moment I opened the door, a wall of sweaty feet and damp shoes met me, thick enough to taste. The bunks were narrow and packed close together. Sometime in the night Chris gave up entirely and moved out of the room to sleep somewhere he could breathe.

Day 3: The northern peaks

This was the hardest day of the trip, and the best. We spent about eight hours on the trail, most of it above treeline, hopping from rock to rock. I had to watch every step. Mile after mile, the terrain kept us moving slowly and deliberately.

We went over the top of Mount Clay (5,533 ft), then climbed Mount Jefferson (5,712 ft), and passed Thunderstorm Junction, a huge cairn near Mount Adams where several trails meet.

Somewhere along the ridge I developed a couple of blisters, which I patched before they could take over. The heat asked for the same kind of upkeep: I drank three liters of water and took two electrolyte tablets, and I was still craving salt by dinner, when I dumped extra on my pasta shells.

One of my favorite parts of the hike was meeting AT thru-hikers. Much of the ridge follows the Appalachian Trail, and many of them were already months into their journey from Georgia to Maine. They were friendly and much faster than we were. You could often recognize them by their strong legs, and sometimes by their strong smell, though after three days without a shower, I was hardly one to talk.

We reached Madison Spring Hut in the early evening. This time my bunk was at the top of a stack four beds high, which I started calling "the fourth floor." It was close enough to the ceiling that I learned not to sit up too fast. At my age, nature tends to call at least once a night. From the fourth floor, that meant logging extra vertical miles. By now, though, the snoring and thin mattresses barely registered.

Day 4: Down to the burger

The last day was a long walk down. We left Madison Spring Hut and followed the Valley Way Trail back into the trees and eventually to the car we had left days earlier.

On the way down, I realized I felt different from how I had at the end of the Pemi Loop. There, every mile had made me more tired and weaker. This time I was more tired but also stronger. Maybe it was the hut meals, the lighter pack, or the daily electrolytes. Whatever the reason, my legs were sore but moving better than they had on the first day.

Our timing was lucky. By evening, after we were safely off the trail, winds had reached gale force and hail was sweeping across the mountains.

We celebrated our escape the only sensible way: with burgers at Black Mountain Burger in Lincoln. Hut food is generous, but after four days it is not this. That burger tasted better than any summit we climbed.

The four-thousand-footers we climbed

New Hampshire hikers chase a famous list of forty-eight peaks over four thousand feet. In the years I have lived in New England, I have climbed quite a few of them.

To make the list, a mountain has to rise at least two hundred feet above the col, the saddle connecting it to its taller neighbor. That rule is why Mount Franklin and Mount Clay, both well over four thousand feet, do not count. They are really shoulders of bigger mountains.

Of the peaks we crossed, Franklin and Clay were also the only two not named for presidents. Benjamin Franklin and Henry Clay never reached the White House, and their mountains never reached the list. The two men who did not make it became the two mountains that did not count.

By the two-hundred-foot rule, we summited four: Pierce, Eisenhower, Washington, and Jefferson. We came up just short of Adams and walked past Monroe and Madison, which means the Presidentials still owe us a return trip.

When I think about the trip, I do not remember the blisters or the bunkrooms first. I remember standing next to Chris at sunset while the ridges faded from blue to gray, one behind another.

My legs are still sore, but I am already wondering where to hike next.