DrupalCon Rotterdam 2026 is going to be way more than just sessions and keynotes, it’s a chance to be part of what actually builds and improves Drupal. 

Contribution Day is a part of DrupalCon, and in Rotterdam it will be on Thursday, 01 Oct. This is the heart of the event, where the global community comes together to make a real and concrete impact to the project.

If you’re planning your trip, we highly encourage you to stay for Thursday. It’s the most rewarding day of the conference. Whether you write code, improve documentation, help with UX, fix bugs, or support translations, there’s a place for every skill level. 

And better still, you don’t need any prior contribution experience, just curiosity and willingness to get involved. You’ll be guided by experienced mentors, collaborate with many contributors from around the world, and leave with new connections, new skills and something meaningful you helped create. 

If you've never contributed before, this is the perfect moment to start!

So, what are you waiting for? 
Let’s do it!

Contribution Day in Rotterdam on 01 Oct.

By Scott Falconer, Product Lead, Outside AI

Where Drupal really stands with AI agents, where it has a right to win, and what we need to do next.

AI agents can build with almost anything. That is both great news and a problem for Drupal.

A person can ask an agent to recommend a platform, rebuild an existing site, create a content model, configure permissions, or change a running system. The agent then has to decide whether Drupal is a good path, reach it, understand it, act on it, and verify the result.

When that experience fails, we usually do not get a bug report. The agent works around Drupal, produces something that only looks finished, or quietly chooses another stack. 

That makes agent experience a growth problem for Drupal, not just a developer-experience problem.

Drupal does not need to be the fastest way to generate any page. Drupal should be the safest, clearest way to a governed, inspectable, long-lived site - and agents should be able to use it effectively.

By governed, we mean the controls that make a site safe to run and hand off - a real content model, scoped roles and permissions, review and audit, safe rollback - not just quick to generate.

This is the purpose of Outside AI, the workstream the Drupal AI Initiative launched: making Drupal legible, callable, safe, and verifiable for agents and builder tools operating from the outside.

The distinction from Inside AI, in shorthand:

• Inside AI: a person uses Drupal, and Drupal uses AI to help.
• Outside AI: a person uses an agent, and the agent uses Drupal.

These are different experiences, but they need substantially the same foundation: clear state, stable interfaces, scoped identity, governed actions, and reliable verification. Wherever possible, that foundation should be built once in Drupal and shared by both.

Our goal is not to make Drupal better for agents instead of people. It is to make Drupal's existing strengths explicit enough that both agents and people can safely use them. If we are successful we will make Drupal's strengths visible and attainable - improvements that hold no matter which agent, model, or tooling wins.

Where Drupal really is

Early measurements from the Drupal Agent Readiness Scorecard point to a tricky but useful conclusion: capability is becoming table stakes.

Our first-hour study drops a cold agent onto each platform with no prior setup and measures how fast and how reliably it can stand up a small but real structured, permissioned site. The bar: a content model, seeded content, a public page, a scoped editor role. Every milestone is confirmed by an independent HTTP probe, not the agent's own say-so. Agents cleared that bar on every platform we tested: Drupal CMS, bare Drupal core, WordPress, and a from-scratch Node app (each across multiple models and two agent families), plus single spot-check runs on Wagtail, Joomla, Strapi, and Payload.

The evidence is still early and deliberately narrow - and the scorecard is useful for direction, but "can an agent build with Drupal?" is no longer an open question.

The better questions: when should an agent choose Drupal, how far can it reliably get, and what is left after the agent is done?

Drupal has an advantage here. It was not designed for agents - but it was not luck, either.

For two decades, enterprise and community pressure forced Drupal to care about structured content, relationships, roles and permissions, editorial workflows, configuration management, APIs, and migration. Complex digital experiences demanded structure, governance, and safe ways to change things, so the community built them.

Those are exactly the things agents need: structured state they can inspect, explicit permissions they can reason about, actions with known boundaries, configuration they can hand off, and evidence that a change worked. The foundation was already here. AI is now revealing why it matters.

And agents do find it. In the study's Drupal runs, agents reached for native capabilities - content types, roles, permissions, Views, exported configuration - instead of bypassing Drupal with a static lookalike, and what they left behind was inspectable. That evidence is promising, but as Dries wrote about Drupal's role in agentic workflows, a head start is not a plan to win. What this post attempts to measure is where the head start is real, where it is not, and what we need to do to turn it into a win.

Drupal still makes agents work too hard to reach the advantage. Setup choices, authentication, module selection, stale assumptions, unclear action surfaces, and weak verification can consume the whole first session before Drupal's strengths become visible.

Agents do not reward us for architecture they never reach.

The advantage is made of decisions

Drupal core, contrib, and products like Drupal CMS are best understood not just as software, but as an accumulation of hard-fought decisions by many dedicated individuals: core is the architectural commitments (structured content, revisions, granular permissions), contrib the solved problems (search, forms, spam, SEO), and a product like Drupal CMS the curation - which of those a serious site actually needs, working together from day one. That accumulated judgment is the real inheritance, and the hard part to reproduce on any stack.

What makes those decisions unusually legible, inspectable, and reusable - without reading the code that enforces them - is that Drupal represents most of them as structured configuration: data with a schema, exportable to files, reviewable as a diff, and inspectable on a running site. Content types and fields, role grants, Views, editorial workflows - they all live there. That standard is the point: Drupal gives decisions a common, inspectable place to live. On a from-scratch build there is no such defined place - a decision may sit in code, a migration, an ad-hoc config file, or only in someone's head. On some headless CMSs, even the access rules are code. Drupal keeps an unusually large share of the decision surface legible as data.

That is what a human actually inherits from an agent-built Drupal site: decisions they did not know to ask for, in a form they can inspect and safely change. An agent building from scratch gives you exactly what it thought of. An agent building on Drupal CMS hands you the community's accumulated judgment - core's architecture, contrib's solved problems, the product's curation - as artifacts you can review, compare, export or change through the admin UI or by applying a recipe, without a developer touching code. When we verified agent builds, we did not take the agent's summary - we read the configuration. Decisions-as-data is what made that possible: legible, deployable between environments of the same site, composable across sites as recipes, and checkable by someone who was not in the room.

This is where Drupal's advantage can also become fragile - a decision can be structured and still be lost, bypassed, or stripped of its rationale:

• The config/code boundary can be a failure point. Configuration declares a desired state that one line of code can silently bypass. The access-coverage probe (which requests a restricted resource through every serving path an anonymous user could reach) found exactly this shape: custom code called ->accessCheck(FALSE) on an entity query and then exposed the returned entities without a later entity-access check, bypassing the access filtering the site otherwise expected. A site's true behavior is the intersection of config and code, and verification that reads only one layer misses the other.
• Configuration records what was decided, rarely why. It can carry labels, descriptions, and dependencies, but there is no first-class model for the rationale behind a decision or how future changes should treat it. The hard-fought decision arrives stripped of its reasoning.
• Configuration does not defend the intent behind a valid change. It can defend structural validity and dependencies, but not the human judgment a change quietly discards. In the recipe-composition tests - where we combined recipes that touch the same settings - two recipes applied conflicting config actions to the same property and the later action won mechanically. In the intent experiments - where we recorded the reason behind a design decision in the site itself, then asked a fresh agent to make a conflicting change - agents read the stored rationale and then removed the very affordances it was meant to protect.

So "those decisions aren't lost" turns out to be an assumption, not a guarantee - in these tests, it did not hold on its own… but the answer is not to freeze the decisions: the agent acts for the user, and sometimes changing one is exactly right. In the intent experiments the rationale was in the site, and the agents even read it - it still never entered the change. Our bet is timing: move the reason to the moment - keep it attached to the work, and put it in front of the agent exactly when it is about to change what that reason protects. The agent may still make the change; sometimes it should, but it is a tradeoff the agent had the opportunity to evaluate with the right context at the right moment.

And the stakes are rarely one big decision. A long-lived site is changed by many actors over many years - people and agents, each change small on its own. No single lost decision reads as damage; the damage is the trajectory. Small silent losses compound, change after change, until the governed site someone carefully built has drifted into something nobody chose. The advantage accumulated one hard-fought decision at a time, and it erodes the same way - which is why the lever has to sit at the moment of change, the same granularity where the drift happens. The advantage is made of decisions, for as long as you can remember them. 

Where Drupal has a right to win

The Playing to Win choice cascade rests on one premise: strategy is a choice.

A disposable landing page, a one-off prototype, or a deeply bespoke product where a CMS addresses only a small slice of the job may be better served by a different stack. Drupal does not need to win every prompt to win the work it is built for.

This is the practical consequence of the great CMS unbundling: AI commoditizes creation while raising the value of control - it lowers the cost of creation, not the cost of trust.

Drupal has a right to win when the result must remain understandable and operable after generation:

• Content-rich sites with a real editorial model.
• Sites with multiple roles, permissions, and approval boundaries.
• Sites that must ensure high quality and accurate content.
• Long-lived systems that teams of people and agents will change.
• Rebuilds and migrations where the source site's decisions cannot simply be discarded.
• Projects where configuration, deployment, auditability, and recovery matter.
• Sites where "it looks done" is not the same as "it is safe to operationalize."

This territory is defined by the work, not the organization's size. A small nonprofit can need strong editorial governance. A large enterprise will often find a disposable microsite sufficient for the right use cases.

In the language of the cascade:

• Winning aspiration: Drupal becomes the clearest, most trustworthy CMS choice for an external agent building a real, governed site.
• Where we play: work where structure, governance, handoff, and long-term operability matter.
• How we win: close enough of the first-session gap that Drupal gets considered, then prove the result is more inspectable, verifiable, and trustworthy.
• Capabilities we need: start and connect, understand the site, act through governed interfaces, verify and recover, and rebuild or launch through a repeatable path.
• How we measure it: fixed tasks, real running sites, retained failures and nulls, and independently checked outcomes.

How this gets more people to Drupal

Drupal's historical adoption barrier is not that it is powerful. It is that reaching the power has usually required someone who already knows Drupal.

A committed Drupal agency invests through that friction because it knows what is on the other side. A WordPress shop that occasionally considers Drupal, a system integrator with many platforms to choose from, or a lean in-house team may not.

AI can lower the expertise barrier - but only if the results can be trusted.

If an agent can absorb more of the repeatable setup and assembly, while experts review the consequential architecture, business, and governance decisions, then Drupal expertise moves up the value stack. Talented people spend their time on customer experience, editorial strategy, integrations, and the decisions that actually differentiate the site.

Prove that path and the agency pitch changes from:

We can build this after a substantial discovery and setup phase.

to:

We have already built a governed starting position. Here is the architecture, what we learned from the source site, which Drupal decisions we inherited, what we verified, and where expert judgment is still required.

That is a stronger way to enter a rebuild conversation - and it is how Drupal becomes a realistic choice for teams that do not already have deep Drupal expertise in-house.

It is still a strategic bet. We have not demonstrated that better agent experience produces Drupal adoption at scale, and we should not claim the market outcome before we have proven the mechanism. We would know the bet was wrong if agents kept bypassing Drupal's native capabilities even when they were easy to reach, if inspectable artifacts did not measurably cut a second team's time to change a site safely, or if entry friction never fell far enough for Drupal to enter consideration at all.

The first session should not require a laptop

Underneath the expertise barrier sits a second one: the environment. Local tooling for Drupal provides an excellent experience - DDEV can stand up a real site in minutes for someone who lives in a terminal. The same first-hour measurements ran on exactly that tooling, and even there, install weight - not capability - set the pace. And that is the expert path: it assumes a capable machine, a terminal, a container runtime, and the time to configure them. A growing share of first evaluations do not start there. They start on a phone, in a browser tab, or inside a chat window - often mediated by an agent that has no local machine at all.

No amount of polish can remove that local barrier. And to be clear, this is not a criticism of tools like DDEV - DDEV should remain the expert path. But if the only way to try Drupal is to install Drupal, we lose the people - and the agents - who were only willing to spend five curious minutes. We risk rejection before the first page is ever built.

That is why hosted try-and-build surfaces matter: places where someone who does not know or care about Drupal yet - or an agent acting on their behalf - can start a real site with nothing installed. Hosted trials, browser-based build environments, demo workflows, commercial platform starters, and one-click hosting paths each attack that floor from a different angle. And each has a natural graduation path: a trial becomes a real site, and a real site launches onto hosted platforms as it grows. The front door feeds the installed base.

This is also where the community structure of the Drupal AI initiative becomes its advantage. No single on-ramp will fit every user, and each provider brings its own vision, market, and opinions - a browser trial optimizes for the five-curious-minutes case, a demo workflow for build-something-real, a commercial platform for launch-and-scale. That plurality is a strength, on one condition: the Drupal underneath must be the same agent-ready Drupal everywhere - the same state introspection, the same governed actions, the same verification. Providers should compete on experience and opinion, not re-invent the substrate.

The standard: someone who has never heard of PHP or SQL - or an agent with no machine at all - can go from curiosity to a real, governed Drupal site in one session, and graduate that site to production hosting without starting over.

What we need to build

From here the essay turns into inside baseball: issue by issue, for the people working with Drupal every day. If that is not you, feel free to skim, or skip to the closing.

The Outside AI roadmap follows the journey an external agent has to complete - the same path Dries has sketched, from setup to connection, context, governed action, validation, recovery, and launch. These five stages assume Drupal is already in the running; getting there - an agent discovering Drupal, recognizing the task fits its territory, and reaching a starting surface before any Drupal site exists - is stage zero, and it is what the front door and self-description work above are for. In the below, we focus on what we should be able to say, with evidence, before calling it done. And wherever external tooling has to keep explaining the same Drupal quirk to an agent, that quirk is a roadmap item: the workaround is the requirements document.

1. Start and connect

An agent needs supported ways into Drupal and a scoped, auditable identity - and there is still a lot to decide in what that identity can be. An agent can act as a delegate, carrying a scoped slice of the authority of the person it works for. Or it can act as an independent, non-human account with grants of its own - a principal actor. These are two different models of what an agent is, with different strengths: delegation cannot exceed the person it acts for, which keeps the blast radius small and the audit trail human-shaped; an independent identity can carry work no single person's permissions cover, like scheduled maintenance or operations across many sites.

Drupal should not pick the winner. Products, hosts, and teams will choose differently - reasonably - and the same site may run both. From the substrate's side, the fork matters less than it looks: both models need the same structure - a grant that is scoped, an action that is attributed, a denial that is auditable. Build those once and either model, or both at once, can run on top. 

The mechanics are arriving. The core CLI entry point (vendor/bin/dr) landed in Drupal 11.4. Work on the execution principal, OAuth behavior, and MCP scope enforcement continues across the initiative: the execution-principal plan, OAuth identity work in Simple OAuth, and scope handling in the MCP Server module. No single entry point serves every environment: dr is a local and server transport, while a remote agent needs authenticated HTTP or MCP. What has to stay constant is the contract - the same action, authorization, and receipt model, reachable through the right transport for each.

The standard: given an agent operating under a scoped grant - delegated from a person or issued to a non-human identity - when it attempts an allowed action, the action succeeds and is recorded against an execution principal that names both the initiator and the executor. When it attempts an action beyond that grant, it fails clearly, safely, and with an auditable reason.

2. Understand the running site

The agent should not have to guess what Drupal or the running site can tell it. We need supported, machine-readable inventory, site structure, API and schema fidelity, path ownership, available actions, and current constraints.

The standard: given a running Drupal site, when an agent requests site context, it can discover content types, fields, roles, permissions, workflows, path ownership, enabled extensions, available actions, and relevant constraints - without scraping the UI or guessing from routes.

3. Act through governed interfaces

Agents need typed inputs, predictable errors, least-privilege execution, approval boundaries, and results another system can inspect.

This fundamental is one Drupal's entity layer already demonstrates: authorization attaches to the operation, not the entry point. An editor does not write to the database - they work through forms their permissions allow, and when a change goes through the Entity API, the same permission and entity-access checks fire whether it arrived from the admin UI or the API. For agents, that is the right foundation: no separate "agent mode" to secure - a new caller walks through a new door and hits the same wall. It is not yet universal: some checks still live at the door, and the command line has historically carried implicit authority - which is exactly why the execution-principal work in stage one matters. Part of the roadmap is making the fundamental universal, not inventing it.

What is missing is declaration, not governance. Entity CRUD is well covered - JSON:API exposes entities as resources under the same policies. But the operations beyond CRUD - clear a cache, apply a recipe, run a migration, reindex search - are scattered across admin forms, Drush commands, and one-off endpoints, each with its own shape. An agent cannot reliably discover what operations exist, what they require, or what they return; efforts like the Tool API and tool declaration introspection are working toward that declared catalog. The requirement is the fundamental, not any one module: one action model, many doors - typed inputs, the same authorization, and a structured receipt from every transport. A receipt, though, is still a claim - judging it is the next stage's job.

The standard: given one declared site action, when an agent calls it through any supported action adapter - CLI, MCP, ECA, or Drupal's AI systems - its typed inputs, authorization, errors, and result receipts behave consistently. Where an operation is entity CRUD through JSON:API, the same identity and authorization policies apply.

4. Verify and recover

The agent's own summary should not be held as proof - we would never expect a human to be the ideal judge of their own work. What matters is what the site actually shows. That is not a new problem: Drupal has always worked on it, because Drupal was never just for managing content - it manages how a team works together. Work does not count until someone else - or a system-enforced guardrail - says it does: drafts, moderation states, revision history with rollback, a permission model where the author does not have to be the approver. An agent is the newest actor in that system: it proposes within its permissions, the workflow gates what counts as done, a different actor approves, and revisions makes it reversible.

That machinery is fundamental to Drupal for content. For code and configuration, teams already have a mature review lane too - it just lives outside Drupal, in version control. And Drupal is unusually well placed to use it: because configuration exports to files, a config change can ride the same discipline as code - a diff, a pull request, a reviewer, CI, a revert. That is decisions-as-data paying off; most platforms cannot put their settings in a code review at all. An agent that works like a developer - building locally, exporting configuration, committing - inherits all of it.

The live site is the harder case, and not just for agents: a person doing site-building on production creates the same risk. Teams manage it by deciding where each kind of change is allowed to happen. Content is edited live, because live content has mechanisms for review. Structure is built in a development copy and flows to production through configuration import - so a config change made directly on production is temporary, and the next deployment erases it; some teams block live config edits outright. Giving an agent the same working agreement needs nothing new: a role that edits content on production, a freer hand in a development copy, the config path in between.

Two things are new though, and as a result they are the roadmap. First, the working agreement has to be explicit. Teams usually write it down for people - onboarding docs, locked-down production, review - but with agents, every session can be somebody's first day on the site, so anything left as "on the job" knowledge repeatedly fails fast. The boundary has to be stated by the site, and feedback given when it is enforced; the explicitness a cold agent needs is the same explicitness that protects a new hire.

Second, speed and scale. Where a team produced a handful of reviewable changes a day, agents can produce thousands. Human review alone does not survive that volume. Independent, automated verification has to absorb it - machine checks covering the routine, so human attention lands on the judgment calls. AI observability can trace requests through standard logging and telemetry, but tracing a request is not the same as independently verifying a change or rolling it back; the checking itself has to become machinery.

Our work is to extend the team discipline Drupal already applies to content - draft, review, approve, revert - to every surface an agent can change, at a speed and scale no site team has faced before.

The standard: given a change the agent claims is complete, when an independent process inspects the site, it can confirm what changed, show which content, configuration, code, or workflow surface was touched, report whether verification passed, and provide a preview, rollback, or recovery path.

5. Rebuild, migrate, and launch

The same governed path has to support a real way onto Drupal and a real handoff toward production. That includes source audits and discovery, content and pattern mapping, Drupal-native architecture advice, redirects, Canvas and configuration integrity, parity evidence, editorial review, and an explicit boundary between structured Migrate API work and agent-led re-architecture.

Issues such as Canvas configuration data integrity and reconciling updates to already-imported default content are part of this path even though they do not carry an "AI" label. 

The standard: given a real source site, when an agent proposes or builds a Drupal replacement, the handoff includes source-site findings, mapped content and patterns, Drupal-native architecture, parity evidence, unresolved gaps, and a clear line where human judgment is required before launch.

Measurement is the spine across all five. The Drupal Agent Readiness Scorecard exists to tell us whether Drupal improved while the workflow held steady - separately from the normal improvement of the models themselves.

Rotterdam should prove direction, not victory

The Rotterdam plan - the proof we are aiming to have ready by DrupalCon Rotterdam - is intentionally narrow: one real rebuild of an existing non-Drupal site into Drupal CMS. The question it answers is precise: can an outside operator turn a real non-Drupal site into a defensible Drupal starting position, with independently reviewable evidence?

• The operator should be outside the Drupal CMS team.
• The source site should contain enough structural complexity to require judgment.
• The result should include a source audit, a governed Drupal build, recorded decisions, independent verification, and explicit gaps.
• A Drupal expert should review it against a predeclared rubric - architecture, permissions, content integrity, editorial usability, maintainability, verification evidence, and known gaps.
• The final question should be binary: would that expert stake their name on this as a sound starting position for a senior team?

The bar we’re setting is not, are we "ready to launch.", it is "is this defensible enough to continue?"

One successful build would demonstrate a viable path in that case. A second site with a second operator would begin to test repeatability. Neither would prove that the market has moved - and we should not claim otherwise.

The question then is what remains after the agent is done. A clear test is: give the finished build to a fresh person or agent with none of the original context, and ask them to make a consequential change safely - add an editorial role, alter a workflow without weakening access, explain why the architecture is what it is, recover from a deliberately broken change - while we measure time-to-understand, mistakes, expert intervention, and whether the site's own state carried the reasoning. That tests "decisions as data" far more directly than a second build.

A head start is not a win

Drupal already has much of what builders need for serious sites. Again, that is the good news.

But the bad news is that potential has little value if agents reject Drupal before reaching it.

We should be careful not to declare victory because Drupal has structured content, permissions, workflows, and configuration management -  The work that remains is to turn those properties into a clear, measurable advantage: make Drupal easy enough to choose, explicit enough to understand, safe enough to change, and verifiable enough to trust.

Outside AI needs real workflows more than speculative feature lists. If you are using an external agent to build with Drupal, calling Drupal from another system, or encountering friction anywhere from setup through launch, bring us the real task.

A use case, failed run, repeated workaround, missing capability, or existing issue is enough; you do not need to arrive with a solution or even know where the work belongs. Add it to the Outside AI meta issue or bring it to the #ai-initiative channel in Drupal Slack. We will help reproduce it, map it to the agent journey, connect it with the right maintainers and implementation work, and determine whether it belongs in the scorecard.

If you maintain a project agents need to use, tell us what they repeatedly misunderstand or work around. Those workarounds are requirements documents.

Drupal's earned advantage gives us the right to play. What we build, and what we prove next, determines whether we win.

Evidence note: the measurements described here are early and deliberately narrow; several are exploratory rather than claim-grade. The scorecard work publishes fixed tasks, retained failures and nulls, explicit evidence boundaries, and paired pre/post results before claiming that Drupal itself improved.
 

By Scott Falconer, Product Lead, Outside AI

Where Drupal really stands with AI agents, where it has a right to win, and what we need to do next.

AI agents can build with almost anything. That is both great news and a problem for Drupal.

A person can ask an agent to recommend a platform, rebuild an existing site, create a content model, configure permissions, or change a running system. The agent then has to decide whether Drupal is a good path, reach it, understand it, act on it, and verify the result.

When that experience fails, we usually do not get a bug report. The agent works around Drupal, produces something that only looks finished, or quietly chooses another stack. 

That makes agent experience a growth problem for Drupal, not just a developer-experience problem.

Drupal does not need to be the fastest way to generate any page. Drupal should be the safest, clearest way to a governed, inspectable, long-lived site - and agents should be able to use it effectively.

By governed, we mean the controls that make a site safe to run and hand off - a real content model, scoped roles and permissions, review and audit, safe rollback - not just quick to generate.

This is the purpose of Outside AI, the workstream the Drupal AI Initiative launched: making Drupal legible, callable, safe, and verifiable for agents and builder tools operating from the outside.

The distinction from Inside AI, in shorthand:

• Inside AI: a person uses Drupal, and Drupal uses AI to help.
• Outside AI: a person uses an agent, and the agent uses Drupal.

These are different experiences, but they need substantially the same foundation: clear state, stable interfaces, scoped identity, governed actions, and reliable verification. Wherever possible, that foundation should be built once in Drupal and shared by both.

Our goal is not to make Drupal better for agents instead of people. It is to make Drupal's existing strengths explicit enough that both agents and people can safely use them. If we are successful we will make Drupal's strengths visible and attainable - improvements that hold no matter which agent, model, or tooling wins.

Where Drupal really is

Early measurements from the Drupal Agent Readiness Scorecard point to a tricky but useful conclusion: capability is becoming table stakes.

Our first-hour study drops a cold agent onto each platform with no prior setup and measures how fast and how reliably it can stand up a small but real structured, permissioned site. The bar: a content model, seeded content, a public page, a scoped editor role. Every milestone is confirmed by an independent HTTP probe, not the agent's own say-so. Agents cleared that bar on every platform we tested: Drupal CMS, bare Drupal core, WordPress, and a from-scratch Node app (each across multiple models and two agent families), plus single spot-check runs on Wagtail, Joomla, Strapi, and Payload.

The evidence is still early and deliberately narrow - and the scorecard is useful for direction, but "can an agent build with Drupal?" is no longer an open question.

The better questions: when should an agent choose Drupal, how far can it reliably get, and what is left after the agent is done?

Drupal has an advantage here. It was not designed for agents - but it was not luck, either.

For two decades, enterprise and community pressure forced Drupal to care about structured content, relationships, roles and permissions, editorial workflows, configuration management, APIs, and migration. Complex digital experiences demanded structure, governance, and safe ways to change things, so the community built them.

Those are exactly the things agents need: structured state they can inspect, explicit permissions they can reason about, actions with known boundaries, configuration they can hand off, and evidence that a change worked. The foundation was already here. AI is now revealing why it matters.

And agents do find it. In the study's Drupal runs, agents reached for native capabilities - content types, roles, permissions, Views, exported configuration - instead of bypassing Drupal with a static lookalike, and what they left behind was inspectable. That evidence is promising, but as Dries wrote about Drupal's role in agentic workflows, a head start is not a plan to win. What this post attempts to measure is where the head start is real, where it is not, and what we need to do to turn it into a win.

Drupal still makes agents work too hard to reach the advantage. Setup choices, authentication, module selection, stale assumptions, unclear action surfaces, and weak verification can consume the whole first session before Drupal's strengths become visible.

Agents do not reward us for architecture they never reach.

The advantage is made of decisions

Drupal core, contrib, and products like Drupal CMS are best understood not just as software, but as an accumulation of hard-fought decisions by many dedicated individuals: core is the architectural commitments (structured content, revisions, granular permissions), contrib the solved problems (search, forms, spam, SEO), and a product like Drupal CMS the curation - which of those a serious site actually needs, working together from day one. That accumulated judgment is the real inheritance, and the hard part to reproduce on any stack.

What makes those decisions unusually legible, inspectable, and reusable - without reading the code that enforces them - is that Drupal represents most of them as structured configuration: data with a schema, exportable to files, reviewable as a diff, and inspectable on a running site. Content types and fields, role grants, Views, editorial workflows - they all live there. That standard is the point: Drupal gives decisions a common, inspectable place to live. On a from-scratch build there is no such defined place - a decision may sit in code, a migration, an ad-hoc config file, or only in someone's head. On some headless CMSs, even the access rules are code. Drupal keeps an unusually large share of the decision surface legible as data.

That is what a human actually inherits from an agent-built Drupal site: decisions they did not know to ask for, in a form they can inspect and safely change. An agent building from scratch gives you exactly what it thought of. An agent building on Drupal CMS hands you the community's accumulated judgment - core's architecture, contrib's solved problems, the product's curation - as artifacts you can review, compare, export or change through the admin UI or by applying a recipe, without a developer touching code. When we verified agent builds, we did not take the agent's summary - we read the configuration. Decisions-as-data is what made that possible: legible, deployable between environments of the same site, composable across sites as recipes, and checkable by someone who was not in the room.

This is where Drupal's advantage can also become fragile - a decision can be structured and still be lost, bypassed, or stripped of its rationale:

• The config/code boundary can be a failure point. Configuration declares a desired state that one line of code can silently bypass. The access-coverage probe (which requests a restricted resource through every serving path an anonymous user could reach) found exactly this shape: custom code called ->accessCheck(FALSE) on an entity query and then exposed the returned entities without a later entity-access check, bypassing the access filtering the site otherwise expected. A site's true behavior is the intersection of config and code, and verification that reads only one layer misses the other.
• Configuration records what was decided, rarely why. It can carry labels, descriptions, and dependencies, but there is no first-class model for the rationale behind a decision or how future changes should treat it. The hard-fought decision arrives stripped of its reasoning.
• Configuration does not defend the intent behind a valid change. It can defend structural validity and dependencies, but not the human judgment a change quietly discards. In the recipe-composition tests - where we combined recipes that touch the same settings - two recipes applied conflicting config actions to the same property and the later action won mechanically. In the intent experiments - where we recorded the reason behind a design decision in the site itself, then asked a fresh agent to make a conflicting change - agents read the stored rationale and then removed the very affordances it was meant to protect.

So "those decisions aren't lost" turns out to be an assumption, not a guarantee - in these tests, it did not hold on its own… but the answer is not to freeze the decisions: the agent acts for the user, and sometimes changing one is exactly right. In the intent experiments the rationale was in the site, and the agents even read it - it still never entered the change. Our bet is timing: move the reason to the moment - keep it attached to the work, and put it in front of the agent exactly when it is about to change what that reason protects. The agent may still make the change; sometimes it should, but it is a tradeoff the agent had the opportunity to evaluate with the right context at the right moment.

And the stakes are rarely one big decision. A long-lived site is changed by many actors over many years - people and agents, each change small on its own. No single lost decision reads as damage; the damage is the trajectory. Small silent losses compound, change after change, until the governed site someone carefully built has drifted into something nobody chose. The advantage accumulated one hard-fought decision at a time, and it erodes the same way - which is why the lever has to sit at the moment of change, the same granularity where the drift happens. The advantage is made of decisions, for as long as you can remember them. 

Where Drupal has a right to win

The Playing to Win choice cascade rests on one premise: strategy is a choice.

A disposable landing page, a one-off prototype, or a deeply bespoke product where a CMS addresses only a small slice of the job may be better served by a different stack. Drupal does not need to win every prompt to win the work it is built for.

This is the practical consequence of the great CMS unbundling: AI commoditizes creation while raising the value of control - it lowers the cost of creation, not the cost of trust.

Drupal has a right to win when the result must remain understandable and operable after generation:

• Content-rich sites with a real editorial model.
• Sites with multiple roles, permissions, and approval boundaries.
• Sites that must ensure high quality and accurate content.
• Long-lived systems that teams of people and agents will change.
• Rebuilds and migrations where the source site's decisions cannot simply be discarded.
• Projects where configuration, deployment, auditability, and recovery matter.
• Sites where "it looks done" is not the same as "it is safe to operationalize."

This territory is defined by the work, not the organization's size. A small nonprofit can need strong editorial governance. A large enterprise will often find a disposable microsite sufficient for the right use cases.

In the language of the cascade:

• Winning aspiration: Drupal becomes the clearest, most trustworthy CMS choice for an external agent building a real, governed site.
• Where we play: work where structure, governance, handoff, and long-term operability matter.
• How we win: close enough of the first-session gap that Drupal gets considered, then prove the result is more inspectable, verifiable, and trustworthy.
• Capabilities we need: start and connect, understand the site, act through governed interfaces, verify and recover, and rebuild or launch through a repeatable path.
• How we measure it: fixed tasks, real running sites, retained failures and nulls, and independently checked outcomes.

How this gets more people to Drupal

Drupal's historical adoption barrier is not that it is powerful. It is that reaching the power has usually required someone who already knows Drupal.

A committed Drupal agency invests through that friction because it knows what is on the other side. A WordPress shop that occasionally considers Drupal, a system integrator with many platforms to choose from, or a lean in-house team may not.

AI can lower the expertise barrier - but only if the results can be trusted.

If an agent can absorb more of the repeatable setup and assembly, while experts review the consequential architecture, business, and governance decisions, then Drupal expertise moves up the value stack. Talented people spend their time on customer experience, editorial strategy, integrations, and the decisions that actually differentiate the site.

Prove that path and the agency pitch changes from:

We can build this after a substantial discovery and setup phase.

to:

We have already built a governed starting position. Here is the architecture, what we learned from the source site, which Drupal decisions we inherited, what we verified, and where expert judgment is still required.

That is a stronger way to enter a rebuild conversation - and it is how Drupal becomes a realistic choice for teams that do not already have deep Drupal expertise in-house.

It is still a strategic bet. We have not demonstrated that better agent experience produces Drupal adoption at scale, and we should not claim the market outcome before we have proven the mechanism. We would know the bet was wrong if agents kept bypassing Drupal's native capabilities even when they were easy to reach, if inspectable artifacts did not measurably cut a second team's time to change a site safely, or if entry friction never fell far enough for Drupal to enter consideration at all.

The first session should not require a laptop

Underneath the expertise barrier sits a second one: the environment. Local tooling for Drupal provides an excellent experience - DDEV can stand up a real site in minutes for someone who lives in a terminal. The same first-hour measurements ran on exactly that tooling, and even there, install weight - not capability - set the pace. And that is the expert path: it assumes a capable machine, a terminal, a container runtime, and the time to configure them. A growing share of first evaluations do not start there. They start on a phone, in a browser tab, or inside a chat window - often mediated by an agent that has no local machine at all.

No amount of polish can remove that local barrier. And to be clear, this is not a criticism of tools like DDEV - DDEV should remain the expert path. But if the only way to try Drupal is to install Drupal, we lose the people - and the agents - who were only willing to spend five curious minutes. We risk rejection before the first page is ever built.

That is why hosted try-and-build surfaces matter: places where someone who does not know or care about Drupal yet - or an agent acting on their behalf - can start a real site with nothing installed. Hosted trials, browser-based build environments, demo workflows, commercial platform starters, and one-click hosting paths each attack that floor from a different angle. And each has a natural graduation path: a trial becomes a real site, and a real site launches onto hosted platforms as it grows. The front door feeds the installed base.

This is also where the community structure of the Drupal AI initiative becomes its advantage. No single on-ramp will fit every user, and each provider brings its own vision, market, and opinions - a browser trial optimizes for the five-curious-minutes case, a demo workflow for build-something-real, a commercial platform for launch-and-scale. That plurality is a strength, on one condition: the Drupal underneath must be the same agent-ready Drupal everywhere - the same state introspection, the same governed actions, the same verification. Providers should compete on experience and opinion, not re-invent the substrate.

The standard: someone who has never heard of PHP or SQL - or an agent with no machine at all - can go from curiosity to a real, governed Drupal site in one session, and graduate that site to production hosting without starting over.

What we need to build

From here the essay turns into inside baseball: issue by issue, for the people working with Drupal every day. If that is not you, feel free to skim, or skip to the closing.

The Outside AI roadmap follows the journey an external agent has to complete - the same path Dries has sketched, from setup to connection, context, governed action, validation, recovery, and launch. These five stages assume Drupal is already in the running; getting there - an agent discovering Drupal, recognizing the task fits its territory, and reaching a starting surface before any Drupal site exists - is stage zero, and it is what the front door and self-description work above are for. In the below, we focus on what we should be able to say, with evidence, before calling it done. And wherever external tooling has to keep explaining the same Drupal quirk to an agent, that quirk is a roadmap item: the workaround is the requirements document.

1. Start and connect

An agent needs supported ways into Drupal and a scoped, auditable identity - and there is still a lot to decide in what that identity can be. An agent can act as a delegate, carrying a scoped slice of the authority of the person it works for. Or it can act as an independent, non-human account with grants of its own - a principal actor. These are two different models of what an agent is, with different strengths: delegation cannot exceed the person it acts for, which keeps the blast radius small and the audit trail human-shaped; an independent identity can carry work no single person's permissions cover, like scheduled maintenance or operations across many sites.

Drupal should not pick the winner. Products, hosts, and teams will choose differently - reasonably - and the same site may run both. From the substrate's side, the fork matters less than it looks: both models need the same structure - a grant that is scoped, an action that is attributed, a denial that is auditable. Build those once and either model, or both at once, can run on top. 

The mechanics are arriving. The core CLI entry point (vendor/bin/dr) landed in Drupal 11.4. Work on the execution principal, OAuth behavior, and MCP scope enforcement continues across the initiative: the execution-principal plan, OAuth identity work in Simple OAuth, and scope handling in the MCP Server module. No single entry point serves every environment: dr is a local and server transport, while a remote agent needs authenticated HTTP or MCP. What has to stay constant is the contract - the same action, authorization, and receipt model, reachable through the right transport for each.

The standard: given an agent operating under a scoped grant - delegated from a person or issued to a non-human identity - when it attempts an allowed action, the action succeeds and is recorded against an execution principal that names both the initiator and the executor. When it attempts an action beyond that grant, it fails clearly, safely, and with an auditable reason.

2. Understand the running site

The agent should not have to guess what Drupal or the running site can tell it. We need supported, machine-readable inventory, site structure, API and schema fidelity, path ownership, available actions, and current constraints.

The standard: given a running Drupal site, when an agent requests site context, it can discover content types, fields, roles, permissions, workflows, path ownership, enabled extensions, available actions, and relevant constraints - without scraping the UI or guessing from routes.

3. Act through governed interfaces

Agents need typed inputs, predictable errors, least-privilege execution, approval boundaries, and results another system can inspect.

This fundamental is one Drupal's entity layer already demonstrates: authorization attaches to the operation, not the entry point. An editor does not write to the database - they work through forms their permissions allow, and when a change goes through the Entity API, the same permission and entity-access checks fire whether it arrived from the admin UI or the API. For agents, that is the right foundation: no separate "agent mode" to secure - a new caller walks through a new door and hits the same wall. It is not yet universal: some checks still live at the door, and the command line has historically carried implicit authority - which is exactly why the execution-principal work in stage one matters. Part of the roadmap is making the fundamental universal, not inventing it.

What is missing is declaration, not governance. Entity CRUD is well covered - JSON:API exposes entities as resources under the same policies. But the operations beyond CRUD - clear a cache, apply a recipe, run a migration, reindex search - are scattered across admin forms, Drush commands, and one-off endpoints, each with its own shape. An agent cannot reliably discover what operations exist, what they require, or what they return; efforts like the Tool API and tool declaration introspection are working toward that declared catalog. The requirement is the fundamental, not any one module: one action model, many doors - typed inputs, the same authorization, and a structured receipt from every transport. A receipt, though, is still a claim - judging it is the next stage's job.

The standard: given one declared site action, when an agent calls it through any supported action adapter - CLI, MCP, ECA, or Drupal's AI systems - its typed inputs, authorization, errors, and result receipts behave consistently. Where an operation is entity CRUD through JSON:API, the same identity and authorization policies apply.

4. Verify and recover

The agent's own summary should not be held as proof - we would never expect a human to be the ideal judge of their own work. What matters is what the site actually shows. That is not a new problem: Drupal has always worked on it, because Drupal was never just for managing content - it manages how a team works together. Work does not count until someone else - or a system-enforced guardrail - says it does: drafts, moderation states, revision history with rollback, a permission model where the author does not have to be the approver. An agent is the newest actor in that system: it proposes within its permissions, the workflow gates what counts as done, a different actor approves, and revisions makes it reversible.

That machinery is fundamental to Drupal for content. For code and configuration, teams already have a mature review lane too - it just lives outside Drupal, in version control. And Drupal is unusually well placed to use it: because configuration exports to files, a config change can ride the same discipline as code - a diff, a pull request, a reviewer, CI, a revert. That is decisions-as-data paying off; most platforms cannot put their settings in a code review at all. An agent that works like a developer - building locally, exporting configuration, committing - inherits all of it.

The live site is the harder case, and not just for agents: a person doing site-building on production creates the same risk. Teams manage it by deciding where each kind of change is allowed to happen. Content is edited live, because live content has mechanisms for review. Structure is built in a development copy and flows to production through configuration import - so a config change made directly on production is temporary, and the next deployment erases it; some teams block live config edits outright. Giving an agent the same working agreement needs nothing new: a role that edits content on production, a freer hand in a development copy, the config path in between.

Two things are new though, and as a result they are the roadmap. First, the working agreement has to be explicit. Teams usually write it down for people - onboarding docs, locked-down production, review - but with agents, every session can be somebody's first day on the site, so anything left as "on the job" knowledge repeatedly fails fast. The boundary has to be stated by the site, and feedback given when it is enforced; the explicitness a cold agent needs is the same explicitness that protects a new hire.

Second, speed and scale. Where a team produced a handful of reviewable changes a day, agents can produce thousands. Human review alone does not survive that volume. Independent, automated verification has to absorb it - machine checks covering the routine, so human attention lands on the judgment calls. AI observability can trace requests through standard logging and telemetry, but tracing a request is not the same as independently verifying a change or rolling it back; the checking itself has to become machinery.

Our work is to extend the team discipline Drupal already applies to content - draft, review, approve, revert - to every surface an agent can change, at a speed and scale no site team has faced before.

The standard: given a change the agent claims is complete, when an independent process inspects the site, it can confirm what changed, show which content, configuration, code, or workflow surface was touched, report whether verification passed, and provide a preview, rollback, or recovery path.

5. Rebuild, migrate, and launch

The same governed path has to support a real way onto Drupal and a real handoff toward production. That includes source audits and discovery, content and pattern mapping, Drupal-native architecture advice, redirects, Canvas and configuration integrity, parity evidence, editorial review, and an explicit boundary between structured Migrate API work and agent-led re-architecture.

Issues such as Canvas configuration data integrity and reconciling updates to already-imported default content are part of this path even though they do not carry an "AI" label. 

The standard: given a real source site, when an agent proposes or builds a Drupal replacement, the handoff includes source-site findings, mapped content and patterns, Drupal-native architecture, parity evidence, unresolved gaps, and a clear line where human judgment is required before launch.

Measurement is the spine across all five. The Drupal Agent Readiness Scorecard exists to tell us whether Drupal improved while the workflow held steady - separately from the normal improvement of the models themselves.

Rotterdam should prove direction, not victory

The Rotterdam plan - the proof we are aiming to have ready by DrupalCon Rotterdam - is intentionally narrow: one real rebuild of an existing non-Drupal site into Drupal CMS. The question it answers is precise: can an outside operator turn a real non-Drupal site into a defensible Drupal starting position, with independently reviewable evidence?

• The operator should be outside the Drupal CMS team.
• The source site should contain enough structural complexity to require judgment.
• The result should include a source audit, a governed Drupal build, recorded decisions, independent verification, and explicit gaps.
• A Drupal expert should review it against a predeclared rubric - architecture, permissions, content integrity, editorial usability, maintainability, verification evidence, and known gaps.
• The final question should be binary: would that expert stake their name on this as a sound starting position for a senior team?

The bar we’re setting is not, are we "ready to launch.", it is "is this defensible enough to continue?"

One successful build would demonstrate a viable path in that case. A second site with a second operator would begin to test repeatability. Neither would prove that the market has moved - and we should not claim otherwise.

The question then is what remains after the agent is done. A clear test is: give the finished build to a fresh person or agent with none of the original context, and ask them to make a consequential change safely - add an editorial role, alter a workflow without weakening access, explain why the architecture is what it is, recover from a deliberately broken change - while we measure time-to-understand, mistakes, expert intervention, and whether the site's own state carried the reasoning. That tests "decisions as data" far more directly than a second build.

A head start is not a win

Drupal already has much of what builders need for serious sites. Again, that is the good news.

But the bad news is that potential has little value if agents reject Drupal before reaching it.

We should be careful not to declare victory because Drupal has structured content, permissions, workflows, and configuration management -  The work that remains is to turn those properties into a clear, measurable advantage: make Drupal easy enough to choose, explicit enough to understand, safe enough to change, and verifiable enough to trust.

Outside AI needs real workflows more than speculative feature lists. If you are using an external agent to build with Drupal, calling Drupal from another system, or encountering friction anywhere from setup through launch, bring us the real task.

A use case, failed run, repeated workaround, missing capability, or existing issue is enough; you do not need to arrive with a solution or even know where the work belongs. Add it to the Outside AI meta issue or bring it to the #ai-initiative channel in Drupal Slack. We will help reproduce it, map it to the agent journey, connect it with the right maintainers and implementation work, and determine whether it belongs in the scorecard.

If you maintain a project agents need to use, tell us what they repeatedly misunderstand or work around. Those workarounds are requirements documents.

Drupal's earned advantage gives us the right to play. What we build, and what we prove next, determines whether we win.

Evidence note: the measurements described here are early and deliberately narrow; several are exploratory rather than claim-grade. The scorecard work publishes fixed tasks, retained failures and nulls, explicit evidence boundaries, and paired pre/post results before claiming that Drupal itself improved.
 

By Christoph Breidert, Product Lead, Inside AI

A year into the Drupal AI Initiative, AI inside of Drupal has a clear goal for the months ahead. At DrupalCon Rotterdam at the end of September, we want to show a single Drupal site where AI Search, an AI chatbot, AI content review, and AI translation all work together on real, multilingual content, with observability and security running underneath. The idea is simple: rather than describe these features one by one, let people see them working together on one site.

This post is about how we plan to get there, what our partners told us to build, and the team we are putting together to build it.

Two streams, working side by side

If you are new to the split, the Drupal AI Initiative now runs in two streams. “Inside AI” is AI inside Drupal, for the people using it. “Outside AI” is AI outside Drupal, acting on it through external agents. The simplest way to hold them apart is this: with Inside AI a person uses Drupal and Drupal uses AI to help; with Outside AI a person uses an agent and the agent uses Drupal. We introduced the two streams in an earlier post, and the distributed leadership structure behind them shortly after. This post is about the AI functionality we are building inside Drupal. Outside AI, led by Scott Falconer, will get its own update, and Dries Buytaert has already written about why that stream matters.

We asked the Drupal AI Partners what to build

Here is something we have not shared publicly before. We asked our Drupal AI Partners, the organizations that fund and staff this initiative, which features they most want us to build inside Drupal. The results were clear.

1. AI search
2. AI content reviews
3. AI translation
4. Chat-driven content editing
5. AI-powered bulk content updates

Search was the standout. The next four clustered closely together, which tells us there is no single second priority so much as a group of capabilities people want in roughly equal measure. This shapes what we prioritize. Drupal AI is funded by our partners, therefore we build what they asked for, in the order they asked for it, against the public 2026 roadmap already in flight.

Two of these deserve a word. We have already been building chat-driven content editing in Canvas AI, and that work continues. Bulk content updates we are not tackling as a standalone feature yet, but it belongs naturally with content review. Once you can review a large body of content with AI, the obvious next step is letting AI help you act on what it found, so for now it lives within the content review work rather than as a separate capability.

Shippable features, proven in the demo

What matters most to anyone building with Drupal AI is shippable features. The demo is how we prove they are ready, by showing each one working on a real site rather than only in isolation. That is why the demo is the most important thing we are building this year: it turns a list of capabilities into features our partners can put in front of their own clients. The two are not separate efforts. The recipes and configurations that make a feature work in the demo are largely the same ones that make it adoptable on a real project, so building the demo is how shippability becomes visible.

This is also why we are putting real effort into engaging, realistic demo content, a site with enough depth that the AI has something meaningful to search, review, and translate. The goal is for anyone to try it out with a single click and see for themselves how a fully AI-powered CMS behaves.
 

AI Search in Drupal 

Search is a natural place to begin, since it was the most requested feature. Picture a search that returns an AI-generated summary, the sources behind it, and the ranked results below, the way modern web search now works, but over your own site's content.

Search sits alongside the other capabilities, and each carries real weight in the demo. A chatbot drawing on the same retrieval foundation. Content review that scores a page against criteria like brand, legal, and reading level and suggests concrete fixes. Translation that moves content across languages with quality worth presenting. And underneath it all, the observability and security layers that make the experience credible for production rather than a set of features that only hold up one at a time.

Being realistic about the work that remains

This is worth setting out clearly, because it changes what leading one of these areas involves. Most of these features already work today. The gap is usually not the core capability. The gap is that we have not yet shipped the recipes and demo configurations that make them work end to end, with results we are happy to show, on one realistic site.

This is the classic "it works" problem. Yes, it works in isolation. Making it work completely, convincingly, and repeatedly in a demo is a different kind of effort. So the leadership across these areas comes in two shapes. Some of it is making it work in the demo, building the recipe, wiring it to real content, and tuning prompts and results until the output is good enough to present. Some of it is net-new implementation, where the capability still needs to be built or substantially extended. Both are genuine leadership, and we are clear with anyone stepping in about which kind of work their area involves.

The team that gets us there

None of this happens without the hard work of our contributors. To strengthen our governance model, we have chosen to place responsibility for each area in the hands of a dedicated lead, someone who owns its direction and keeps a clear, public backlog for contributors to work from. The sprints themselves do not change. What changes is that every area now has a clear owner, and together these leads form the Inside AI leadership team.

Workflow Drupal AI Leads

Here is where each Inside AI area stands today.

Two things are worth making explicit, because they shape whether you picture yourself in that table.

First, a name beside an area does not mean you cannot join this focus area. The opposite is true. We are looking for strong teams rather than single owners, so contributing to an area that already has a lead is as real an opportunity as taking on one that is open.

Second, there is no formal application process. Becoming a lead happens through the work itself. A lead prepares issues and keeps the backlog in good shape. Our delivery managers, Arian Raeesi and Vidit Anjaria, plan those issues into the sprints. Some go through joint grooming with the technical leads, Marcus Johansson and Artem Dmitriiev, to check they fit the architecture, and I stay involved as product lead to keep them aligned with the overall product direction.

If one of these areas interests you, reach out in the #ai-initiative channel on Drupal Slack, or to any of us directly, and begin. Taking on that responsibility is what makes you a lead, and it is how you join the Inside AI leadership team.

Come and build it with us

This is where AI inside Drupal stands today. We know what our partners want, because we asked. We know where we want to show it working, at Rotterdam, on one site. And we know the only way to get there is together, with a team that owns each part of it.

If you have read this far, there is a good chance one of these areas already appeals to you. Come and say so in the #ai-initiative channel on Drupal Slack, or explore becoming a Drupal AI Partner. The demo will be better with your help, and so will Drupal.
 

By Christoph Breidert, Product Lead, Inside AI

A year into the Drupal AI Initiative, AI inside of Drupal has a clear goal for the months ahead. At DrupalCon Rotterdam at the end of September, we want to show a single Drupal site where AI Search, an AI chatbot, AI content review, and AI translation all work together on real, multilingual content, with observability and security running underneath. The idea is simple: rather than describe these features one by one, let people see them working together on one site.

This post is about how we plan to get there, what our partners told us to build, and the team we are putting together to build it.

Two streams, working side by side

If you are new to the split, the Drupal AI Initiative now runs in two streams. “Inside AI” is AI inside Drupal, for the people using it. “Outside AI” is AI outside Drupal, acting on it through external agents. The simplest way to hold them apart is this: with Inside AI a person uses Drupal and Drupal uses AI to help; with Outside AI a person uses an agent and the agent uses Drupal. We introduced the two streams in an earlier post, and the distributed leadership structure behind them shortly after. This post is about the AI functionality we are building inside Drupal. Outside AI, led by Scott Falconer, will get its own update, and Dries Buytaert has already written about why that stream matters.

We asked the Drupal AI Partners what to build

Here is something we have not shared publicly before. We asked our Drupal AI Partners, the organizations that fund and staff this initiative, which features they most want us to build inside Drupal. The results were clear.

1. AI search
2. AI content reviews
3. AI translation
4. Chat-driven content editing
5. AI-powered bulk content updates

Search was the standout. The next four clustered closely together, which tells us there is no single second priority so much as a group of capabilities people want in roughly equal measure. This shapes what we prioritize. Drupal AI is funded by our partners, therefore we build what they asked for, in the order they asked for it, against the public 2026 roadmap already in flight.

Two of these deserve a word. We have already been building chat-driven content editing in Canvas AI, and that work continues. Bulk content updates we are not tackling as a standalone feature yet, but it belongs naturally with content review. Once you can review a large body of content with AI, the obvious next step is letting AI help you act on what it found, so for now it lives within the content review work rather than as a separate capability.

Shippable features, proven in the demo

What matters most to anyone building with Drupal AI is shippable features. The demo is how we prove they are ready, by showing each one working on a real site rather than only in isolation. That is why the demo is the most important thing we are building this year: it turns a list of capabilities into features our partners can put in front of their own clients. The two are not separate efforts. The recipes and configurations that make a feature work in the demo are largely the same ones that make it adoptable on a real project, so building the demo is how shippability becomes visible.

This is also why we are putting real effort into engaging, realistic demo content, a site with enough depth that the AI has something meaningful to search, review, and translate. The goal is for anyone to try it out with a single click and see for themselves how a fully AI-powered CMS behaves.
 

AI Search in Drupal 

Search is a natural place to begin, since it was the most requested feature. Picture a search that returns an AI-generated summary, the sources behind it, and the ranked results below, the way modern web search now works, but over your own site's content.

Search sits alongside the other capabilities, and each carries real weight in the demo. A chatbot drawing on the same retrieval foundation. Content review that scores a page against criteria like brand, legal, and reading level and suggests concrete fixes. Translation that moves content across languages with quality worth presenting. And underneath it all, the observability and security layers that make the experience credible for production rather than a set of features that only hold up one at a time.

Being realistic about the work that remains

This is worth setting out clearly, because it changes what leading one of these areas involves. Most of these features already work today. The gap is usually not the core capability. The gap is that we have not yet shipped the recipes and demo configurations that make them work end to end, with results we are happy to show, on one realistic site.

This is the classic "it works" problem. Yes, it works in isolation. Making it work completely, convincingly, and repeatedly in a demo is a different kind of effort. So the leadership across these areas comes in two shapes. Some of it is making it work in the demo, building the recipe, wiring it to real content, and tuning prompts and results until the output is good enough to present. Some of it is net-new implementation, where the capability still needs to be built or substantially extended. Both are genuine leadership, and we are clear with anyone stepping in about which kind of work their area involves.

The team that gets us there

None of this happens without the hard work of our contributors. To strengthen our governance model, we have chosen to place responsibility for each area in the hands of a dedicated lead, someone who owns its direction and keeps a clear, public backlog for contributors to work from. The sprints themselves do not change. What changes is that every area now has a clear owner, and together these leads form the Inside AI leadership team.

Workflow Drupal AI Leads

Here is where each Inside AI area stands today.

Two things are worth making explicit, because they shape whether you picture yourself in that table.

First, a name beside an area does not mean you cannot join this focus area. The opposite is true. We are looking for strong teams rather than single owners, so contributing to an area that already has a lead is as real an opportunity as taking on one that is open.

Second, there is no formal application process. Becoming a lead happens through the work itself. A lead prepares issues and keeps the backlog in good shape. Our delivery managers, Arian Raeesi and Vidit Anjaria, plan those issues into the sprints. Some go through joint grooming with the technical leads, Marcus Johansson and Artem Dmitriiev, to check they fit the architecture, and I stay involved as product lead to keep them aligned with the overall product direction.

If one of these areas interests you, reach out in the #ai-initiative channel on Drupal Slack, or to any of us directly, and begin. Taking on that responsibility is what makes you a lead, and it is how you join the Inside AI leadership team.

Come and build it with us

This is where AI inside Drupal stands today. We know what our partners want, because we asked. We know where we want to show it working, at Rotterdam, on one site. And we know the only way to get there is together, with a team that owns each part of it.

If you have read this far, there is a good chance one of these areas already appeals to you. Come and say so in the #ai-initiative channel on Drupal Slack, or explore becoming a Drupal AI Partner. The demo will be better with your help, and so will Drupal.
 

QA Accounts enables you to login to a Drupal site using a well known username/password combination. When 1.0 was released, it also was marked for security coverage. The module prioritizes ease of use rather than security and is only intended to be used on sites that are not accessible on the internet (e.g. behind firewall or other protection). The maintainers are choosing to remove security coverage.

Ensure qa_accounts is not enabled on any publicly available site.

• Jordan Barnes (j-barnes)

• Jakob P (japerry)

The Drupal project runs one of the most disciplined coordinated-disclosure programs in open source, and it has done so through volunteer effort for more than two decades. Millions of sites, many operated by governments, universities, and enterprises, depend on it.

This post is the first in a series stemming from the Drupal AI Security Initiative. Before I dive into how it's organized and what we've found, I wanted to share a post about how Drupal Security Team already works, because the initiative is built to supplement that foundation, not to repair or replace it. Note: this post assumes you are familiar with coordinated disclosure, CVEs, and severity scoring in general and focuses on what Drupal specifically does.

Coordinated disclosure, on a fixed cadence

Reports arrive in a private queue. A Security Team member takes triage duty on a two-week rotation, confirming whether a report is a real, in-scope vulnerability. Once validated, the affected project's maintainer and the original reporter collaborate in the confidential issue where the fix is written, reviewed, and scheduled. All of this stays out of public view until the fix and security advisory are ready on a release day.

Drupal has a predictable release cadence:  advisories publish on Wednesdays, with a Public Service Announcement the Monday before on the very rare occasion a highly critical release warrants advance warning. 

Scoring and identifiers

Every advisory carries a risk score using a system rating each issue 0–25 across six factors (access complexity, privilege required, confidentiality and integrity impact, exploit availability, and target distribution) mapped to labels from Not Critical to Highly Critical. Drupal's risk system was developed based on the NIST Common Misuse Scoring System. The project is now considering moving to CVSS, a more widely adopted standard. Drupal is also a CVE Numbering Authority, so it assigns its own CVEs: a level of formality most community projects don't reach. Summary data about the security track record is public with full details available as a series of posts or a JSON API with data going back to 2006.

What’s public and what stays private

The line between disclosure and discretion is drawn sharply. After release, advisories include all necessary details: affected project, severity, vulnerability type, affected versions, remediation, any possible mitigating factors, and CVE. Before release, the member disclosure policy permits a trusted insider to share only what is already public plus the bare numeric severity, never the affected project, the nature of the bug, or how to mitigate it. Members can't even let an employer market the fact that an employee had early knowledge.

Protection at the network layer

To protect site owners in the window between disclosure and patching, the Security Team and the Drupal Association offer Drupal Steward. Drupal Steward is a web application firewall (WAF) where Drupal Association engineers work with the engineers who wrote the security advisory to develop a rule that blocks the exploit at the request layer that goes live the moment the advisory does. This provides a virtual patch for highly critical, mass-exploitable bugs, but is not a replacement for patching.

The coverage model and its scope

Scope is defined just as clearly. Advisories cover Drupal core, plus contributed projects hosted on Drupal.org that opt into coverage (marked with a shield icon), and only for stable releases. Some things are deliberately out of scope: external libraries a module depends on and bugs requiring high-level administrative permissions. When a maintainer is unreachable, the team can mark a project unsupported.

By design the team is largely reactive: it responds to reports rather than continuously auditing Drupal core and tens of thousands of contributed modules. Members are asked for a few hours a month, a valuable contribution from highly skilled and in-demand individuals. The process is solid, but bandwidth has always been the primary bottleneck.

Scaling our response in the AI Era

Addressing that bottleneck is the whole point of this effort. It's also the founding premise of Alpha-Omega's Security Engineers in Residence program funding: that threat volume and pace are outrunning what volunteer hours can cover. AI has lowered the cost of finding and exploiting vulnerabilities. It enables high-volume report generation and can infer what a quietly worded commit was really fixing. A security process built around scarce attention and a modest head start now faces adversaries operating at machine speed.

Drupal’s security workflows are mature, documented, and trusted. The challenge now is scaling Drupal’s defensive bandwidth and throughput to match that offensive speed. That's what the Drupal AI Security Initiative adds, and it's the subject of the next post in this series.

If you'd like to help in the meantime, the most valuable things any contributor can do are what the team has always relied on: write secure code, report issues responsibly, and, if you have a track record in the community,  consider joining the Security Team.

Tiffany Farriss authored this post and is responsible for its content. Members of the Drupal AI Security Initiative (Greg Knaddison, Tim Lehnen, and Drew Webber) and George DeMet contributed context, editing, and review. AI tools (Claude by Anthropic and Gemini by Google) assisted with research, organization, and editing. All facts were verified by humans against primary sources.

The Drupal project runs one of the most disciplined coordinated-disclosure programs in open source, and it has done so through volunteer effort for more than two decades. Millions of sites, many operated by governments, universities, and enterprises, depend on it.

This post is the first in a series stemming from the Drupal AI Security Initiative. Before I dive into how it's organized and what we've found, I wanted to share a post about how Drupal Security Team already works, because the initiative is built to supplement that foundation, not to repair or replace it. Note: this post assumes you are familiar with coordinated disclosure, CVEs, and severity scoring in general and focuses on what Drupal specifically does.

Coordinated disclosure, on a fixed cadence

Reports arrive in a private queue. A Security Team member takes triage duty on a two-week rotation, confirming whether a report is a real, in-scope vulnerability. Once validated, the affected project's maintainer and the original reporter collaborate in the confidential issue where the fix is written, reviewed, and scheduled. All of this stays out of public view until the fix and security advisory are ready on a release day.

Drupal has a predictable release cadence:  advisories publish on Wednesdays, with a Public Service Announcement the Monday before on the very rare occasion a highly critical release warrants advance warning. 

Scoring and identifiers

Every advisory carries a risk score using a system rating each issue 0–25 across six factors (access complexity, privilege required, confidentiality and integrity impact, exploit availability, and target distribution) mapped to labels from Not Critical to Highly Critical. Drupal's risk system was developed based on the NIST Common Misuse Scoring System. The project is now considering moving to CVSS, a more widely adopted standard. Drupal is also a CVE Numbering Authority, so it assigns its own CVEs: a level of formality most community projects don't reach. Summary data about the security track record is public with full details available as a series of posts or a JSON API with data going back to 2006.

What’s public and what stays private

The line between disclosure and discretion is drawn sharply. After release, advisories include all necessary details: affected project, severity, vulnerability type, affected versions, remediation, any possible mitigating factors, and CVE. Before release, the member disclosure policy permits a trusted insider to share only what is already public plus the bare numeric severity, never the affected project, the nature of the bug, or how to mitigate it. Members can't even let an employer market the fact that an employee had early knowledge.

Protection at the network layer

To protect site owners in the window between disclosure and patching, the Security Team and the Drupal Association offer Drupal Steward. Drupal Steward is a web application firewall (WAF) where Drupal Association engineers work with the engineers who wrote the security advisory to develop a rule that blocks the exploit at the request layer that goes live the moment the advisory does. This provides a virtual patch for highly critical, mass-exploitable bugs, but is not a replacement for patching.

The coverage model and its scope

Scope is defined just as clearly. Advisories cover Drupal core, plus contributed projects hosted on Drupal.org that opt into coverage (marked with a shield icon), and only for stable releases. Some things are deliberately out of scope: external libraries a module depends on and bugs requiring high-level administrative permissions. When a maintainer is unreachable, the team can mark a project unsupported.

By design the team is largely reactive: it responds to reports rather than continuously auditing Drupal core and tens of thousands of contributed modules. Members are asked for a few hours a month, a valuable contribution from highly skilled and in-demand individuals. The process is solid, but bandwidth has always been the primary bottleneck.

Scaling our response in the AI Era

Addressing that bottleneck is the whole point of this effort. It's also the founding premise of Alpha-Omega's Security Engineers in Residence program funding: that threat volume and pace are outrunning what volunteer hours can cover. AI has lowered the cost of finding and exploiting vulnerabilities. It enables high-volume report generation and can infer what a quietly worded commit was really fixing. A security process built around scarce attention and a modest head start now faces adversaries operating at machine speed.

Drupal’s security workflows are mature, documented, and trusted. The challenge now is scaling Drupal’s defensive bandwidth and throughput to match that offensive speed. That's what the Drupal AI Security Initiative adds, and it's the subject of the next post in this series.

If you'd like to help in the meantime, the most valuable things any contributor can do are what the team has always relied on: write secure code, report issues responsibly, and, if you have a track record in the community,  consider joining the Security Team.

Tiffany Farriss authored this post and is responsible for its content. Members of the Drupal AI Security Initiative (Greg Knaddison, Tim Lehnen, and Drew Webber) and George DeMet contributed context, editing, and review. AI tools (Claude by Anthropic and Gemini by Google) assisted with research, organization, and editing. All facts were verified by humans against primary sources.

I've stepped into the role of interim CEO of the Drupal Association for a limited period, expected to last six to twelve months. My job in that time is to help put the Association on a durable footing. As I undertake that task, I want to start by being direct about where we are and where I'd like to see us go next.

The Drupal stewardship the Association provides costs more every year. That includes running Drupal.org, providing the project infrastructure and putting on DrupalCon. For a long time our events paid for most of it. That stopped being enough several years ago, and we have been covering the gap from our reserves. That is not sustainable, and pretending otherwise would not serve anyone. The Drupal Association releases its financials and 990s every year. (The 2025 audit is expected to be released by the board soon.) An analysis of even just the last few years of publicly available financials tells this story plainly. 

And that is only the part we actually fund. Some of the most critical work of all, like responding to security issues and managing releases, still runs entirely on donated volunteer time or corporate underwriting rather than from an ongoing operating budget. 

The answer is not to ask more of the volunteers, agencies and contributors who have carried this project for two decades. The community’s generosity is the heart of Drupal, and it always will be. The real challenge is that the large enterprises and governments that rely on Drupal every day have never had a clear way to understand or pay for the maintenance and services they use. So the cost has been shouldered by those most engaged in the community and, increasingly, the DA’s cash reserves instead.

Changing that is my priority. Over the coming months I'll be focused on three things.

First, understanding the true cost of the work. I'm modernizing our financial reporting so we can see the full cost of every program and event, including the staff time each one requires, which our current reports don't fully communicate. That will give the board, the staff and the community real transparency into where money goes, which programs deliver the most value and where we’re choosing to invest.

Second, funding each kind of work in the way that fits it. Not every program should look the same. Our utility and infrastructure services can move toward a usage-based model for the enterprises that depend on them. Our ecosystem advocacy needs focused support, because it strengthens Drupal and the Makers who build it.  Our digital-public-good work, the parts that belong to everyone, can be sustained by philanthropy, contribution and as part of the utility and advocacy work. The aim is a regenerative model, where what these utility and advocacy services reinvest into all the ongoing costs that Drupal has as a thriving digital public good, a cycle that can sustain itself rather than a subsidy running down without constant new funding sources.

Third, collaborating with open source colleagues. These challenges aren't ours alone. I want to explore a co-creating shared standard for sustainable use certification with other open source projects facing the same challenges. Working together as a broad open source ecosystem, we can make supporting the open source software that organizations depend on an easy, standardized, normal and expected cost of doing business rather than ad hoc, voluntary and charitable, as it is now. 

This matters beyond our own budget. Stewarded open source is no longer just a code repository. It is critical digital infrastructure. To keep it healthy, all of open source needs reliable ongoing funding from operating budgets as a standard line item. That is how we turn an extractive pattern into a regenerative one, and how Drupal and the community stays strong, open and community-governed for everyone who builds on it. Funding our ongoing work properly is how we protect that.

Those are my thoughts. I’m looking forward to hearing yours. Over the next several weeks I’ll be inviting all parts of the Drupal ecosystem to share what you think, and I'll reflect back what I hear as we go. I intend to earn your trust through what we do over the next several months. Thank you for building this project, and for caring enough to hold the Association to a high standard.

One final note of transparency on my own situation: I own Palantir.net, a Drupal Certified Partner, and I take that conflict seriously. As of July 20, I have stepped back from day-to-day operations there. To prevent any interference and guarantee strictly arm’s-length dealings, we have built a robust and legally-vetted conflict-of-interest framework directly into my interim contract.

I've stepped into the role of interim CEO of the Drupal Association for a limited period, expected to last six to twelve months. My job in that time is to help put the Association on a durable footing. As I undertake that task, I want to start by being direct about where we are and where I'd like to see us go next.

The Drupal stewardship the Association provides costs more every year. That includes running Drupal.org, providing the project infrastructure and putting on DrupalCon. For a long time our events paid for most of it. That stopped being enough several years ago, and we have been covering the gap from our reserves. That is not sustainable, and pretending otherwise would not serve anyone. The Drupal Association releases its financials and 990s every year. (The 2025 audit is expected to be released by the board soon.) An analysis of even just the last few years of publicly available financials tells this story plainly. 

And that is only the part we actually fund. Some of the most critical work of all, like responding to security issues and managing releases, still runs entirely on donated volunteer time or corporate underwriting rather than from an ongoing operating budget. 

The answer is not to ask more of the volunteers, agencies and contributors who have carried this project for two decades. The community’s generosity is the heart of Drupal, and it always will be. The real challenge is that the large enterprises and governments that rely on Drupal every day have never had a clear way to understand or pay for the maintenance they use. So the cost has been shouldered by those most engaged in the community and, increasingly, the DA’s cash reserves instead.

Changing that is my priority. Over the coming months I'll be focused on three things.

First, understanding the true cost of the work. I'm modernizing our financial reporting so we can see the full cost of every program and event, including the staff time each one requires, which our current reports don't fully communicate. That will give the board, the staff and the community real transparency into where money goes, which programs deliver the most value and where we’re choosing to invest.

Second, funding each kind of work in the way that fits it. Not every program should look the same. Our utility and infrastructure services can move toward a usage-based model for the enterprises that depend on them. Our ecosystem advocacy needs focused support, because it strengthens Drupal and the Makers who build it.  Our digital-public-good work, the parts that belong to everyone, can be sustained by philanthropy, contribution and as part of the utility and advocacy work. The aim is a regenerative model, where what these utility and advocacy services reinvest into all the ongoing costs that Drupal has as a thriving digital public good, a cycle that can sustain itself rather than a subsidy running down without constant new funding sources.

Third, collaborating with open source colleagues. These challenges aren't ours alone. I want to explore a co-creating shared standard for sustainable use certification with other open source projects facing the same challenges. Working together as a broad open source ecosystem, we can make supporting the open source software that organizations depend on an easy, standardized, normal and expected cost of doing business rather than ad hoc, voluntary and charitable, as it is now. 

This matters beyond our own budget. Stewarded open source is no longer just a code repository. It is critical digital infrastructure. To keep it healthy, all of open source needs reliable ongoing funding from operating budgets as a standard line item. That is how we turn an extractive pattern into a regenerative one, and how Drupal and the community stays strong, open and community-governed for everyone who builds on it. Funding our ongoing work properly is how we protect that.

Those are my thoughts. I’m looking forward to hearing yours. Over the next several weeks I’ll be inviting all parts of the Drupal ecosystem to share what you think, and I'll reflect back what I hear as we go. I intend to earn your trust through what we do over the next several months. Thank you for building this project, and for caring enough to hold the Association to a high standard.

One final note of transparency on my own situation: I own Palantir.net, a Drupal Certified Partner, and I take that conflict seriously. As of July 20, I have stepped back from day-to-day operations there. To prevent any interference and guarantee strictly arm’s-length dealings, we have built a robust and legally-vetted conflict-of-interest framework directly into my interim contract.

It feels like the right moment to share something I have been looking forward to announcing. The holidays are just beginning, and the Enterprise AI Summit (28 September, Rotterdam) is coming together.

We have been reviewing sessions over the past weeks, and three cases in particular stood out, each solving real problems for real organisations.

Here is a first look at three of the sessions we are excited to share.

THE EUROPEAN PERSONNEL SELECTION OFFICE: CANDIDATE SUPPORT IN 24 LANGUAGES

EPSO is the body responsible for selecting staff across EU institutions, and every year, thousands of candidates ask questions in all 24 official EU languages. With a small team, an enormous volume of work, and zero tolerance for wrong answers, EPSO needed a solution that could keep up.

Antonella Picarella will show us what that solution looks like: an AI-powered support tool on Drupal that now handles 93% of incoming questions automatically, across all 24 languages, with no hallucinations detected on manual checking.

Read more about this session: https://summit.enterprisedrupal.eu/epso.html

THE AMERICAN DIABETES ASSOCIATION: FROM PILOT TO PRODUCTION

When the content is about people's health, accuracy is not optional, and neither is speed.

Hemant Gupta will walk through how the American Diabetes Association moved AI from pilot to daily use across their Drupal platform: editorial assistance, bulk alt text generation, in-editor AI tools, and Word-to-Drupal content pipelines. Editorial teams are using it, the results are documented, and so is the process that got them there.

Read more about this session: https://summit.enterprisedrupal.eu/ada.html

WORLD CANCER DAY: MODERATION AT SCALE, WITH A HUMAN HEART

On World Cancer Day, hundreds of thousands of personal cancer stories are shared in a single day, reaching 500,000 requests per hour with just a small team behind it.

Charles Andrew Revkin and Diego Costa will share how the World Cancer Day team uses Drupal and AI to scale a deeply personal campaign without losing the human touch.

Read more about this session: https://summit.enterprisedrupal.eu/wcd.html

JOIN US ON 28 SEPTEMBER IN ROTTERDAM

The full schedule is taking shape. If you want to see what AI actually looks like when it is deployed, trusted, and working, this is where you will find it.

More information and tickets: https://summit.enterprisedrupal.eu

It feels like the right moment to share something I have been looking forward to announcing. The holidays are just beginning, and the Enterprise AI Summit (28 September, Rotterdam) is coming together.

We have been reviewing sessions over the past weeks, and three cases in particular stood out, each solving real problems for real organisations.

Here is a first look at three of the sessions we are excited to share.

THE EUROPEAN PERSONNEL SELECTION OFFICE: CANDIDATE SUPPORT IN 24 LANGUAGES

EPSO is the body responsible for selecting staff across EU institutions, and every year, thousands of candidates ask questions in all 24 official EU languages. With a small team, an enormous volume of work, and zero tolerance for wrong answers, EPSO needed a solution that could keep up.

Antonella Picarella will show us what that solution looks like: an AI-powered support tool on Drupal that now handles 93% of incoming questions automatically, across all 24 languages, with no hallucinations detected on manual checking.

Read more about this session: https://summit.enterprisedrupal.eu/epso.html

THE AMERICAN DIABETES ASSOCIATION: FROM PILOT TO PRODUCTION

When the content is about people's health, accuracy is not optional, and neither is speed.

Hemant Gupta will walk through how the American Diabetes Association moved AI from pilot to daily use across their Drupal platform: editorial assistance, bulk alt text generation, in-editor AI tools, and Word-to-Drupal content pipelines. Editorial teams are using it, the results are documented, and so is the process that got them there.

Read more about this session: https://summit.enterprisedrupal.eu/ada.html

WORLD CANCER DAY: MODERATION AT SCALE, WITH A HUMAN HEART

On World Cancer Day, hundreds of thousands of personal cancer stories are shared in a single day, reaching 500,000 requests per hour with just a small team behind it.

Charles Andrew Revkin and Diego Costa will share how the World Cancer Day team uses Drupal and AI to scale a deeply personal campaign without losing the human touch.

Read more about this session: https://summit.enterprisedrupal.eu/wcd.html

JOIN US ON 28 SEPTEMBER IN ROTTERDAM

The full schedule is taking shape. If you want to see what AI actually looks like when it is deployed, trusted, and working, this is where you will find it.

More information and tickets: https://summit.enterprisedrupal.eu

All security issues have been migrated from the older security.drupal.org site to our GitLab instance at git.drupalcode.org. This is the latest in a series of steps to improve Drupal’s coordinated vulnerability disclosure tools. We hope this will help in a few ways:

Merge requests for security issues will get automated testing to increase the quality of the releases. (Previously, tests for core security issues had to be triggered manually, and contrib testing was not available.)
GitLab has more automation to help with advisory creation, reducing manual work.
Powerful features like labels, commenting, and thread reviews on merge requests are now possible for security issues as well.

Here are some of the key steps we took:

• We started by evaluating a few solutions. We decided to use the GitLab instance on drupalcode.org.
• We planned how to remap and improve the current features from security.drupal.org and added some labels and automation to private issues on drupalcode.org.
• We made new security issue reporting default to git.drupalcode.org for several months. This helped us could gain confidence in the system, fix bugs, and make improvements.
• While that happened, Neil Drumm worked to create the migration process.
• The migration finally ran from July 9th to July 12th.

This work is possible because of support from the Drupal Association and is very appreciated.

We suppressed most emails during the migration, but a small number of people did get extra notification emails about issues, including old issues. We apologize for any resulting confusion.

How do I use GitLab to submit and manage security issues?

As before, security reports should be submitted by clicking the “Report a security vulnerability” link on the project page. If a project has already migrated public issues to git.drupalcode.org, you may also mark an issue confidential as you open it. The Security Team triages confidential issues for all covered projects.

For more information about how Drupal.org’s GitLab instance works, read our documentation.

You can read about the Security Team’s process in general. There is also a page dedicated to managing security issues on git.drupalcode.org. Those pages likely need updates, so please report any documentation issues in the Security Team Queue..

What do you think?

Let us know your thoughts. If you have feedback about how to further improve the Security Team process, you can file them in the Security Team Queue. If you have issues to report about the GitLab tooling itself on git.drupalcode.org, you can file them in the Drupal.org queue.

The old site does a redirect to the new location for issues and members of the Security Team can get content out of it if anyone notices items missing from the migration.

Thanks to longwave, hestenet, dokumori, drumm, and xjm for help in writing this post.

All security issues have been migrated from the older security.drupal.org site to our GitLab instance at git.drupalcode.org. This is the latest in a series of steps to improve Drupal’s coordinated vulnerability disclosure tools. We hope this will help in a few ways:

Merge requests for security issues will get automated testing to increase the quality of the releases. (Previously, tests for core security issues had to be triggered manually, and contrib testing was not available.)
GitLab has more automation to help with advisory creation, reducing manual work.
Powerful features like labels, commenting, and thread reviews on merge requests are now possible for security issues as well.

Here are some of the key steps we took:

• We started by evaluating a few solutions. We decided to use the GitLab instance on drupalcode.org.
• We planned how to remap and improve the current features from security.drupal.org and added some labels and automation to private issues on drupalcode.org.
• We made new security issue reporting default to git.drupalcode.org for several months. This helped us could gain confidence in the system, fix bugs, and make improvements.
• While that happened, Neil Drumm worked to create the migration process.
• The migration finally ran from July 9th to July 12th.

This work is possible because of support from the Drupal Association and is very appreciated.

We suppressed most emails during the migration, but a small number of people did get extra notification emails about issues, including old issues. We apologize for any resulting confusion.

How do I use GitLab to submit and manage security issues?

As before, security reports should be submitted by clicking the “Report a security vulnerability” link on the project page. If a project has already migrated public issues to git.drupalcode.org, you may also mark an issue confidential as you open it. The Security Team triages confidential issues for all covered projects.

For more information about how Drupal.org’s GitLab instance works, read our documentation.

You can read about the Security Team’s process in general. There is also a page dedicated to managing security issues on git.drupalcode.org. Those pages likely need updates, so please report any documentation issues in the Security Team Queue..

What do you think?

Let us know your thoughts. If you have feedback about how to further improve the Security Team process, you can file them in the Security Team Queue. If you have issues to report about the GitLab tooling itself on git.drupalcode.org, you can file them in the Drupal.org queue.

The old site does a redirect to the new location for issues and members of the Security Team can get content out of it if anyone notices items missing from the migration.

Thanks to longwave, hestenet, dokumori, drumm, and xjm for help in writing this post.

This article is cross-posted with permission from Dries Buytaert's blog.

The Drupal Association is entering a new chapter. Tim Doyle is stepping down as CEO, and the Board has appointed Tiffany Farriss as interim CEO.

I am grateful to Tim for his leadership and his impact on the Association. He built a strong leadership team that helped guide Drupal through an ambitious period of innovation. That team is well positioned to continue supporting Drupal and its community.

Tiffany brings continuity and deep expertise to the Drupal Association. She has contributed to Drupal for many years and served on the Drupal Association Board for more than a decade, including on its Finance Committee. She helped organize DrupalCon and built and ran a successful agency in the Drupal ecosystem. She understands our project, the Association's finances, and the realities our partners, contributors, and users face.

I have worked with Tiffany for many years. She is thoughtful, deeply committed to Drupal, and unafraid of hard questions. Although her title is interim CEO, she has the full authority and confidence of the Board, as well as my full support.

We expect Tiffany to serve for six to twelve months. During that time, she will focus on strengthening the Association's financial and operational foundation and preparing it for long-term leadership. Later in that period, the Board plans to launch a search for the next permanent CEO.

Turning innovation into momentum

Tiffany is stepping into the role at an important moment for Drupal.

Over the past few years, our community has done some of its most ambitious work. Contributors have continued to modernize Drupal Core. We launched Drupal CMS to make Drupal easier to adopt, introduced Drupal Canvas to rethink how people build, and rapidly advanced Drupal AI to change how people create and manage content.

We have also taken important steps toward marketing Drupal with the seriousness it deserves, so more organizations understand why it remains one of the most powerful and trusted platforms for building serious websites and applications.

This progress was made possible by our contributors and the organizations that invest in Drupal every day. The Drupal Association's role is to support that work and help turn it into wider adoption, a stronger ecosystem, and more opportunity for Drupal businesses.

Sustaining Drupal's essential work

The Drupal Association operates much of the infrastructure the project depends on, from Drupal.org and our collaboration tools to the services that help keep Drupal secure.

Drupal's infrastructure alone costs roughly $3 million each year. Today, it is funded through DrupalCon revenue, partnerships, sponsorships, donations, donated services, and volunteer contributions. That model has supported Drupal for many years, but it is not durable enough for the scale of the work ahead.

This is a challenge shared by open-source stewards everywhere. The software may be free to download, but the infrastructure and stewardship that make it dependable are not free to provide.

Building a stronger Drupal Association

Our commitment to Drupal's infrastructure and community will not change. Supporting them well requires a stronger Drupal Association, and that may mean exploring new approaches. We will weigh the options carefully, guided by what is best for Drupal and the people who depend on it.

This work will not be easy, but our ambition is clear: make the Association more sustainable, help Drupal innovate faster, strengthen how we bring it to market, and better support Certified Partners.

As this work takes shape, we will be transparent about what we are learning, the choices we are considering, and what they could mean for the Association and the community.

Tiffany understands what makes Drupal special and what the community values most. She also has the experience and mandate to shape what comes next.

Every new chapter depends on people willing to step forward. I am thankful to Tim for all he has done, to the Association's staff for their dedication, and to Tiffany for taking this on. With their commitment, I am confident in Drupal's direction and excited about the work ahead.

Our CEO, Tim Doyle, has stepped down from his role. We are grateful to Tim for his leadership and impact on our organization. Tim has built a strong leadership team that is positioned to continue the mission and vision that he and the Board share for Drupal.

As part of this process, the Board has been working to identify Tim’s successor. We anticipate that the important work and mission of our organization will continue under new leadership, building on the strategy and plans we led during Tim’s time with Drupal.

Likewise, the Board has been working with the senior team to ensure that interim leadership will be in place to facilitate a smooth transition.

We are grateful to Tim for all of his contributions as the leader of Drupal, and we look forward to his continued success in his future endeavors.

The Drupal Association board has appointed Tiffany Farriss as the Interim CEO, who brings more than a decade of experience as a Drupal Association board member, to guide the organization and community through this transition period.

Join us THURSDAY, July 16 at 1pm ET / 10am PT, for our regularly scheduled call to chat about all things Drupal and nonprofits. (Convert to your local time zone.)

We don't have anything specific on the agenda this month, so we'll have plenty of time to discuss anything that's on our minds at the intersection of Drupal and nonprofits. Got something specific you want to talk about? Feel free to share ahead of time in our collaborative Google document at https://nten.org/drupal/notes!

All nonprofit Drupal devs and users, regardless of experience level, are always welcome on this call.

This free call is sponsored by NTEN.org and open to everyone.

Information on joining the meeting can be found in our collaborative Google document.