26 Aug 2026
Drupal.org aggregator
The Drop Times: DrupalCamp Colorado 2026 Puts Long-Term Drupal Practice in Focus
A training day can introduce a workflow. Thursday's speakers are asking what happens when Drupal systems must survive staff turnover or move content safely between environments.
26 Aug 2026 2:59pm GMT
Omega8.cc: Drupal CMS Runs on Ægir
Waiting for your hosting panel to grow a Drupal CMS platform? The wait ended in late 2025: it has been running on Ægir for many months, rebuilt from the upstream Composer template as BOA releases ship, tracking the version the Drupal project currently publishes. Enabling it is one symbol in a platform list your account already carries, installing a site on it is the usual short panel task, and one honest warning applies: the interactive browser wizard does not run here, the complete package installs unattended, and the deliberately plain front page it greets you with is exactly what a healthy install looks like. From that minute the machine treats it as a normal Drupal 11 site: nightly backups, one-task HTTPS, cloning, Drush, and calm platform-to-platform updates by design - on a server where Pressflow 6, Drupal 7 and Backdrop veterans still serve next door, because continuity here means the whole line stays alive at once.
26 Aug 2026 2:10pm GMT
Stuart Clark (Deciphered): Drupal site settings over JSON:API, per consumer
In April 2022 I wrote about decoupling configuration with Config Pages, and ended it with a guess at where I'd go next:
One of my future experiments with Druxt will be to look at the options of using the Drupal Consumers module alongside Drupal theme settings as a solution.
That experiment is now a module. Decoupled Settings serves the site and theme configuration Drupal already holds over JSON:API, and lets every frontend override just the values it needs. It went up on Drupal.org this week.
Core's JSON:API is an entity API. Content entities and config entities alike, so node types, image styles and views are all in there. What it has never exposed is simple configuration, and there's a good argument that it shouldn't by default, because plenty of what sits in system.site is nobody's business.
But a decoupled frontend still needs the boring stuff:
- The site name, for the document title
- The slogan
- The logo and the favicon
- The front page path, so the router knows what "home" means
So every decoupled build solves it locally, and most of the ways to solve it end up keeping a second copy of the site name somewhere.
26 Aug 2026 9:20am GMT
Dries Buytaert: Finding related posts with embeddings
I added a new feature to my blog: a list of related posts at the bottom of each post. I implemented it using embeddings, and this note documents how.
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. I started with a smaller model that returns 384 numbers and moved up because the matches were better. BAAI's own benchmarks point the same way, though the gap is modest.
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. 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 ] (768 numbers total)
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 almost the same way sit at a small angle, and the cosine of a small angle is close to 1, so 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, so the scores cluster in a high, 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. An old post about the founding of Acquia shows the problem. It covers a lot of ground: Drupal, my PhD, Red Hat and IBM backing Linux, venture capital, and personal reflection. Because it touches so many subjects, its vector sits close to the average of all my posts, and it scored high against almost the entire archive. Its best match scored 0.876, and its hundredth best still scored 0.770.
Mean-centering reveals what makes each post distinct
Anisotropy has several known fixes, from lightest to heaviest. The lightest is mean-centering, which is what I use and what the rest of this section explains.
All-but-the-top 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). I have not tried these others. Mean-centering is one subtraction per vector with no matrix algebra, which keeps the code plain PHP, and it was enough.
You 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, so what remains is what makes each post distinct. That average points down the middle of the cone, the direction my whole blog tends to lean.
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. On my corpus, centering still made the scores much more useful.
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 look somewhat similar. In every post the first number is high and close to the others (0.90, 0.85 and 0.80), so it dominates the comparison. But 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 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.
26 Aug 2026 8:40am GMT
Très Bien Blog: A tool to painlessly update a heavily patched Drupal site
A tool to painlessly update a heavily patched Drupal site
Picture a Drupal 10.6 website with a several months stale composer.json: 120 contrib modules, 47 patches. You need to update it to Drupal 11.4. Many hours will be spent checking I don't want to deal with this several times a year so I improved the Drupal-Code-Query MCP server with a few more tools.
theodore
26 Aug 2026 8:35am GMT
Tag1 Insights: A Warm Afterglow from Laracon US 2026
Laracon US came to my hometown of Boston this year, and a few weeks later I'm still glowing. Here are the moments that stuck with me.
Whimsy-Driven Development
My favorite session was Whimsy-Driven Development by Christina Martinez. Watch it if you want to rekindle the joy of building software. We can build anything we can imagine today, and Christina gives us permission and encouragement to do exactly that. I joined her Silly Software Club on the spot. I haven't built any silly software yet, but I did make a silly image announcing my blended family's upcoming vacation to Mexico.
The Vibes
The day after Laracon wrapped, I attended The Vibes, a daylong summit about NativePHP. NativePHP is an epic piece of software that lets PHP developers build fully native mobile apps, with no web view required. What I loved most was the kindness and enthusiasm of the project's leaders, Simon Hamp and Shane Rosenthal, who walked us through NativePHP like proud parents. The pride was earned. If anyone has a silly mobile app idea, let's build it together.
Laravel and Drupal, Compared
I spend most of my time in the Drupal world, so I couldn't help comparing. The two projects have a lot in common: both are mature open source projects with deep communities. Drupal launched in 2001 and Laravel in 2011, making them 25 and 15 years old. I think Laravel's velocity outpaces Drupal core's. Drupal has more contributors, yet somehow ships less. Some of that is by design: Drupal core emphasizes process: coding standards, esoteric workflows (like issue forks), code review gates, strong backward compatibility. That discipline has real benefits, and it attracts contributors who value it, though others gravitate toward contrib, where the pace is faster. Laravel, by contrast, runs on a "we must ship" mantra. There's something to learn from both cultures. I commend Taylor Otwell for his relentless focus on shipping. It's paying off.
Image credit: Meet Boston
26 Aug 2026 12:00am GMT
25 Aug 2026
Drupal.org aggregator
The Drop Times: Rybbit Analytics Maintainer Explores Embedded Dashboards and No-Code Event Tracking for Drupal
For Drupal sites with logged-in experiences, the integration can use existing user attributes to segment journeys and activity, extending Rybbit beyond anonymous traffic reporting.
25 Aug 2026 1:52pm GMT
Specbee: Are you building a Drupal module that already exists? Meet Module Scout
Building a Drupal module? We built Module Scout that uses AI to search Drupal.org's live project directory and help you find existing modules before you start from scratch.
25 Aug 2026 10:21am GMT
Webpro Company blog: When a Drupal module becomes unsupported because of a security risk
On 19 August 2026, the Drupal.org security advisory page included several contributed projects that the security team marked unsupported because of known security issues. That is not just another update notice. A site owner needs to know whether the module is used on their site and what to do when there is no fixed release. On 19 August 2026, the Drupal.org security advisory page listed several contributed projects that were marked unsupported because of security issues. Examples included Screenshot, Link content parser and Gammu SMS Daemon. A week earlier, advisories also included Quick Tabs, External Authentication, Entity Share Websub, Diff and Commerce PayPal. Not every advisory affects every Drupal site. Some modules are very specific. Some risks apply only under certain…
25 Aug 2026 6:00am GMT
Peoples Blog: If AI Can Build an Application, Why Do We Still Need Software Developers?
If AI can build an application from a simple description, why do we still need software developers?It is a question I have been thinking about recently. AI can now generate code, create interfaces, work with databases, connect APIs and turn an idea into a working prototype surprisingly quickly. I use AI in my own development work, and it has changed the way I build things. Tasks that once took hours can often be completed much faster, and experimenting with new ideas has become much easier.
25 Aug 2026 4:09am GMT
Cheppers: ExperienceKit: Why University Websites Break at Scale, and How to Fix It
No one decides to have an inconsistent university website. It happens one reasonable decision at a time: a department needs a page and the central team is booked, so a local admin builds it. A lab hires a student to make something "more modern." A program office, tired of waiting, spins up a page builder subscription on a corporate card. Each choice makes sense in the moment. Sum a decade of them across two hundred departments, and you get the site every university web team recognizes: thousands of pages, dozens of visual dialects, and a governance document nobody has opened since it was ratified.
25 Aug 2026 12:00am GMT
24 Aug 2026
Drupal.org aggregator
The Drop Times: Eight DAM Decisions for Drupal Teams
A DAM decision changes more than where images are stored. Drupal teams also have to decide which system owns metadata, approvals, transformations, rights, and the published asset lifecycle.
24 Aug 2026 4:33pm GMT
Drupal AI Initiative: Your next website visitor might not be human
For most of the web's history, we have designed digital experiences around a simple assumption: a person will visit our website. That person might arrive through a search engine, follow a campaign link, scan a QR code, or maybe even type the URL into their browser.
AI is changing that... dramatically and rapidly!
People are now asking AI assistants to research products, compare services, explain policies, recommend suppliers and complete tasks on their behalf. Sometimes, they might not even consciously choose AI and are simply guided by seemingly familiar tools like Google 'AI Overviews'. Either way, instead of visiting ten websites, a customer may ask one assistant to gather the relevant information and present a recommendation.
In the near future, that AI assistant could be doing more than reading a web page: checking product availability, requesting information, preparing an application, arranging an appointment or even completing a transaction.
Your next website visitor may not be a person at all, but an AI agent acting on their behalf, which raises a serious question:
Can AI systems understand our organisation, trust our information and interact with our services safely?
Getting to know your new audience
To be useful, AI assistants need to find the right information, understand its meaning and decide whether it is current and trustworthy.
A prospective student asking an assistant to compare courses across several universities, a buyer requesting a shortlist of products that meet detailed technical, ethical and budget requirements - both are now part of your website's audience.
While human visitors use navigation, page layouts, graphic cues and calls to action, AI systems depend more heavily on structured information, descriptive metadata, clear relationships and reliable access to data.
Your web pages may look perfectly clear to a person but remain ambiguous to a machine. For example, a human might understand from the design that one contact address is intended for media enquiries, and another is for customer enquiries, but an AI assistant may not interpret it correctly unless it's represented clearly in the underlying content structure.
The content management decisions you make today will shape how accurately they are represented by AI tomorrow.
Being visible is not the same as being understood
Many organisations are currently focused on whether their content appears in AI-generated answers. That is important, but visibility is only one part of the problem.
An AI system also needs to understand:
- What the organisation offers
- Which information is authoritative
- When the information was last reviewed
- Which products, services or locations it relates to
- Whether regional or language differences apply
- What actions can be taken
- Which information is public and which is restricted
Without this context, AI assistants may rely on outdated pages, confuse similar services or combine information that was never intended to be used together.
Preparing for AI visitors therefore requires more than content. It requires a well-structured and reliably governed source of truth.
Drupal gives content meaning
Drupal treats content as structured information rather than a collection of web pages. A university course, for example, could have defined fields for qualification, fees and application route, rather than burying them in a block of text. That structure is what makes the same content usable well beyond a single page.
For a human visitor, Drupal assembles that information into an attractive and accessible page. For an AI visitor, the same structure makes the information easier to identify, compare and reuse.
You don't need to maintain one version of content for people and another for machines because Drupal allows the same governed content to serve websites, applications, search services and AI agents.
Drupal can become the trusted source behind AI answers
AI systems are powerful, but they are only as dependable as the information and context available to them. The idea of autonomous agents can quickly become uncomfortable when governance is treated as an afterthought: what happens if an agent uses sensitive information, makes an unsuitable change, or you simply can't tell why an action occurred?
Drupal can provide a controlled source of organisational knowledge. Its content model, taxonomy and relationship system describe what information means, not simply where it appears on a page, helping an AI assistant distinguish a current policy from an archived one, or a general contact address from a specialist enquiry route.
The Drupal AI ecosystem is developing capabilities to support this level of governance, including guardrails for requests and responses, observability and activity logging, controlled access to organisational context, provider-independent integrations, and human review and approval workflows.
This is especially valuable for large or complex digital estates, where information is created by multiple departments across different languages and regions.Drupal's advanced AI implementation and integration does not negate all risk from AI usage, but it does give you a stronger foundation for identifying and managing it
Put simply, AI makes content governance essential to digital communication.
Hi, I'm a machine, please can I come in?
Making content understandable is the first step. The next is enabling controlled action
Giving an AI agent access to your digital platform creates an obvious concern: what will it be allowed to see and do?
Drupal has long supported detailed roles and permissions, allowing different users to view, edit, approve or publish specific types of content.
The same principle can be applied to AI visitors. A useful agent may need to inspect content, search records, or carry out an action, but it should never gain unrestricted access to your systems, or expose private content simply because that content exists in the same system. It should only be able to access the information and tools permitted for the person, service or task it represents.
The Drupal AI Initiative organises this work through two connected areas:
- Inside AI, which brings AI assistance into Drupal for editors, marketers and site builders
- Outside AI, which enables external AI agents and tools to connect to and act on Drupal
This changes the role of the content management system from being a 'human experience engine' to being a governed platform through which people, applications and AI agents can understand and interact with your organisation.
Design for people, prepare for agents
Human visitors are not disappearing. People will continue to value clear information, strong design, accessible services and experiences that feel relevant and trustworthy. However, they will increasingly use AI to navigate and make sense of the vast amount of information available to them.
AI readiness can look like a technology challenge, but an AI system cannot reliably represent your brand if the underlying content is fragmented, duplicated or poorly structured.
The organisations that adapt successfully will not choose between human-centred design and machine-readable content. They will build digital platforms that support both by creating information people can understand, data machines can interpret and processes agents can interact with safely.
Your next website visitor might not be human - will your digital platform know exactly how to help them?
Try Drupal today!
24 Aug 2026 2:30pm GMT
A Drupal Couple: The closest thing I have to an answer
Add new comment
24 Aug 2026 2:02pm GMT
Drupal AI Initiative: From Headless CMS to AI Harness: What I Took to Decoupled Days
Article by: Martin Anderson-Clutz. Originally posted on the Acquia blog.
Drupal turns decoupled architecture into a governed AI harness, combining live visual editing with agent-ready content schemas.
Back in March, at EvolveDigital in Toronto, I ran into Preston So. He mentioned that the team behind Decoupled Days was looking for speakers, and that this year the event would be in Montréal. I was interested right away. Drupal Canvas is the most compelling answer I have seen to a problem that has followed decoupled architectures for years, and I wanted that message to reach beyond the Drupal faithful - out to the practitioners who live and breathe headless every day.
The talk I ended up giving was not really about a content management system at all. It was about how Drupal has quietly become something else: a governed harness for artificial intelligence. Here is the argument I made, the demo that seemed to land hardest with the room, and why I think 2026 is the year the trade-offs of going headless finally stop being trade-offs.
Drupal Was Decoupled Before Decoupled Was Cool
Drupal did not arrive late to the headless conversation. Far from it. The community committed to an API-first architecture roughly a decade ago, and a vibrant subcommunity has been refining decoupled patterns ever since. That work produced a spectrum of delivery models rather than a single one: traditional, where Drupal renders everything; progressively decoupled, where a JavaScript front end takes over the parts of the page that benefit from it while editorial preview stays intact; and fully decoupled, where Drupal is a pure API feeding any number of channels.
That range matters, because it means Drupal has never been only a content API. It owns content, delivery, and governance at the same time. The headless-native platforms compete on one of those axes. Drupal competes on all three.
The Headless Bargain, and Why 2026 Voids It
When organizations adopted front-end frameworks like Next.js and Astro, most of them accepted what I think of as the headless bargain. They gained fast front ends and their choice of framework, and in exchange they gave up live visual editing, layout control, and real-time editorial preview. Editors went from composing pages to filling in form fields blind and filing tickets for changes they used to make themselves.
The industry tried to patch around this - bespoke preview services, visual editors bolted onto the front end, what amounted to Storybook pressed into service as a content tool. None of it fully closed the gap.
Drupal Canvas, which shipped as the default editing experience in Drupal CMS 2.0, closes it a different way. It delivers a true-to-life editing workspace where content creators edit layouts live in the browser, and the site still ships as a high-performance decoupled front end. The CMS stopped being the bottleneck and became the conductor. You keep Next.js or Astro, and you get the editorial experience back.
The Bigger Shift: The CMS Became a Harness
Something larger is happening underneath all of this. For most of the last two decades, the job of a CMS was to model content and publish it to channels. Through 2024 and 2025, artificial intelligence showed up inside these platforms as a feature - an assist button in a text box that summarized a paragraph or suggested tags when a human clicked it.
By 2026, that framing is obsolete. Artificial intelligence has become infrastructure rather than an accessory: autonomous agents that run scheduled jobs, batch operations, and real-time triggers. Analysts have adopted new vocabulary to match, from agentic experience platforms to AI-ready content management. Three capabilities now separate a platform that is serious about this from one that is not: the Model Context Protocol (MCP), which lets external agents query and update content through one standard interface; autonomous agents that behave like digital teammates; and answer engine optimization, which structures content so it surfaces accurately inside tools like ChatGPT and Perplexity.
And the whole category is converging on the same destination. Headless-native platforms like Sanity, Contentstack, and Storyblok others are all racing to add agents, automation, and AI-assisted authoring. When everyone is heading for the same place, the differentiator is no longer whether a platform has AI. It is how that AI is governed and orchestrated.
So What Is an AI Harness?
Even the most capable models today are prone to hallucination, blind to context they are not explicitly given, and easy to push outside the bounds of what an organization would allow. That is why almost no one uses a raw model directly. They use a harness: the code around the model that improves the quality, safety, and reliability of what comes back. A harness augments the query, enforces guardrails on input and output, and adds tools that give the model real capabilities.
Think of your AI model as the engine: the part that makes your reasoning system go. The harness is the vehicle built around it: the controls that point it in the right direction, change gears when the situation calls for it, and bring it to a stop when needed.
If you list what a good AI harness needs - structured content the model can reason over, access control, deterministic workflows, versioned and reviewable configuration, and centralized governance - Drupal has shipped every one of those for years, for reasons that had nothing to do with AI. The model at the center is a commodity. It is swappable, replaceable, and never the true value driver. Everything Drupal wraps around it is the durable part.
Which leads to the line I kept coming back to: what drives the value of intelligent systems is your schema, not your prompt. Prompts are transient. Typed fields, entity relationships, and taxonomy give a model unambiguous ground truth instead of prose it has to guess at. And the same JSON:API structure that feeds your decoupled front end is exactly what an external agent inspects and reasons over. Drupal orchestrates the content and context; the external model supplies the intelligence. That division of labor ages far better than trying to build models in-house.
Where You Actually See It Work
Everything above is architecture. The demo is where it becomes visible, and it is the part of the talk the audience responded to most.
I had set up a demo environment for a fictional company called Inspace. Ahead of time, I populated the Context Control Center with the things a real brand would have on hand: a brand guide, a tone of voice, documentation for a component library I had programmatically migrated from Drupal's Mercury design system into Code Components and synced into Astro, and a set of context items describing a new "Executive Suites" offering that Inspace was preparing to launch.
Then, live, I created a new page in Canvas, opened Canvas AI, and gave it one sentence: generate a landing page for the new Executive Suites offering. It went to work, and while it did, I took questions from the audience. A couple of minutes later it had assembled a full landing page out of real components, populated with relevant, on-brand content. To make the point that a human stays in the loop, I dropped an image from the media library into the hero component and published. Then I switched to the Astro app, navigated to the same path, and there was the identical page - every decision the human and the model had made, rendered by the decoupled front end. A complete landing page, start to finish, in a couple of minutes.
The second beat pushed further. The marketing team wants a brand-new component: a call to action for a waitlist. I asked Canvas AI to build a full-width announcement banner with an announcement pill, a headline, a supporting line, and a primary call to action. After a short pause, the component appeared in the Canvas interface - colors on brand, formatting consistent with the rest of the library - with its code fully visible and editable and a live preview I could resize to check different breakpoints. I noted that in the real world you might refine the code yourself or ask Canvas AI to iterate, then saved it to the library, dragged it into the Executive Suites page, and published.
When I reloaded the Astro app, it threw a fatal error, exactly as I had planned. The layout now referenced a component the front end did not know about. One npx canvas push from the command line synced the components, a refresh brought the page back, and the new banner rendered cleanly in the Astro layout. That deliberate stumble made the architecture legible: content edits flow to the front end instantly, but new component code is a real, versioned artifact that moves through a real workflow.
I closed the demo by going back to the Context Control Center, because that is the intelligence that made the rest possible. This is what AI prompt grounding looks like in practice: before a single token is generated, each request is automatically supplied with the brand voice, domain knowledge, and guardrails relevant to the task at hand. Some context items are global and travel with every request. Others are scoped specifically to working in Canvas. Others still apply only to content about the Executive Suites program. All of them were assembled automatically behind those short prompts - which is why one sentence was enough to get on-brand, relevant output. I finished on the form for managing a single context item, showing the range of ways its use can be scoped and restricted. Compliance before generation, not review after.
Why Enterprises Can Trust It
For regulated and enterprise teams, governance is where this stops being a demo and starts being a decision. Drupal is model-agnostic by design: dozens of providers sit behind one abstraction layer, spanning cloud services like OpenAI, Anthropic, and Gemini as well as self-hosted options like Ollama and Mistral for data sovereignty. Swapping providers is a configuration change, not a rewrite of your schemas or your logic.
Agents act inside Drupal's existing permission model which includes the Access Policy API, so the access logic that already governs your people governs your agents too - no separate guardrail layer to maintain. Deterministic orchestration through the Event-Condition-Action (ECA) or FlowDrop frameworks handle rules-based logic that costs no tokens and never hallucinates, which is a useful reminder that the cheapest, most reliable AI call is often the one you do not make. And because that orchestration lives inside the platform as native state machines - ECA for event-driven rules, Maestro for durable, multi-step approvals - stateful business logic runs where the content lives, rather than being stitched together from external webhooks, serverless functions, and third-party glue code. Guardrails filter sensitive data before it leaves the server, and metering tracks token spend by user and role so finance can see what AI actually costs.
An Honest Read
It doesn't serve anyone to pretend one side wins everything, and I said so in Montréal. The headless-native platforms lead on real things: faster time to value, a cleaner developer experience, and more polished agentic tooling in market today. If those are your priorities right now, they are genuine strengths.
Where Drupal leads is open source with no lock-in and dozens of documented APIs, model-agnostic freedom, deep governance and orchestration, and fit for enterprise, multi-brand, and regulated environments. It is also worth remembering the shape of the thing behind it: an open ecosystem moves at the speed of everyone who needs it to, while a single-vendor roadmap moves at the speed of one company's priorities.
The Takeaway
The way I put it at the end of the talk: we gave up the editorial experience to go headless, and in 2026 we stopped having to. The original headless win is now additive with the editorial win, not traded against it. One structured content model can serve four consumers at once - a decoupled front end, editors in Canvas, internal AI agents, and the wider martech stack over MCP.
Drupal is not a CMS with AI features bolted on. It is a governed AI harness that happens to have been building the right foundations for 20 years. If you want to see it for yourself, start with Drupal CMS 2.0 and Canvas, then explore the AI, context, and MCP modules. For teams that would rather not set up and host Drupal themselves, Acquia Source CMS offers a fully managed on-ramp to the same platform. And if you are ready to help shape where this goes, the Drupal AI Initiative is where the work is happening.
Making that case in Montréal was a highlight of my year. If you were in the room, thank you - the questions were sharp, and a few of them changed how I will explain this next time. If you were not, come find me, and we can pick up where the talk left off.
24 Aug 2026 9:50am GMT
The Drop Times: Drupal Security Team Marks 16 Contributed Projects Unsupported in Ten Weeks
The latest three projects have limited reported use, but the pattern extends beyond their reach. For affected site teams, the recurring security response is to uninstall the project rather than install an update.
24 Aug 2026 7:30am GMT