Artificial intelligence is changing how we build, manage, and deliver digital experiences. But AI isn’t just a developer conversation. It’s also a conversation for architects, product owners, marketers, digital strategists, executives, and organisational leaders.

That’s why DrupalCon Rotterdam is introducing two dedicated AI summits on Monday, 28th September. Each has a different focus, but together they provide a complete picture of what AI means for the future of Drupal.

The AI Dev Summit

The AI Dev Summit is built for the people creating the next generation of Drupal experiences.

If you enjoy building, experimenting, and solving technical challenges, this summit is for you. Sessions focus on practical implementation, emerging AI capabilities, and the tools developers need to begin building AI-powered Drupal solutions today.

Topics include:

• AI-assisted development
• Drupal AI and Drupal CMS
• Canvas and modern AI workflows
• Building with AI frameworks and services
• Real-world technical demonstrations
• Best practices from experienced contributors

Whether you’re already working with AI or just beginning to explore what’s possible, the AI Dev Summit offers practical knowledge you can apply immediately.

The Enterprise AI Summit

Technology alone doesn’t create transformation. Organisations also need leadership, governance, strategy, and clear business objectives.

The Enterprise AI Summit focuses on those conversations.

Designed for digital leaders, executives, product managers, architects, and decision-makers, this summit explores how organisations can responsibly adopt AI while delivering measurable value.

Sessions examine questions such as:

• How should organisations develop an AI strategy?
• What governance models are needed?
• Where can AI deliver measurable business value?
• How do security, privacy, and compliance influence adoption?
• What organisational changes are required for successful AI implementation?
• What projects have leading global organisations deployed?

Rather than concentrating on implementation details, this summit focuses on helping organisations make informed decisions about AI.

Different audiences. Shared goals.

While each summit has its own emphasis, they are closely connected.

Successful AI initiatives require both technical expertise and organisational leadership.

Developers need leaders who understand the opportunities and challenges AI presents. Leaders need developers who can turn strategy into working solutions.

By offering both summits, DrupalCon recognises that AI adoption succeeds when technical innovation and business strategy move together.

Which summit should you attend?

Choose the AI Dev Summit if you:

• Build Drupal websites and applications
• Want hands-on technical sessions
• Are interested in Drupal AI, Canvas, and AI development tools
• Enjoy learning by seeing practical demonstrations
• Meet the makers of Drupal AI and expert practioners

Choose the Enterprise AI Summit if you:

• Lead digital strategy or technology initiatives
• Make technology investment decisions
• Manage products, teams, or digital transformation
• Want to understand how AI fits into organisational goals
• Meet leading practitioners and peers who have delivered successful solutions within their organizations

Of course, if your role bridges both worlds, you’ll likely find value in either summit.

Join us in Rotterdam

Whether you’re writing code, defining strategy, or helping your organisation navigate the future of AI, DrupalCon Rotterdam has a summit designed for you.

Whichever path you choose, you’ll leave with practical insights, new connections, and a deeper understanding of how AI is shaping the Drupal ecosystem.

We look forward to seeing you in Rotterdam.

File attachments:  banner_web_3400X720 (002).png

To better serve smaller organizations and those in a budget crunch, we’ve launched Tiny Services.

Anxiety about AI

The Drupal and broader software community are getting overly anxious about the new kids on the block… AI. I wanted to step back and explore this anxiety through the analogy of AI as the new kids on the block, or, more specifically, the new kids entering our software teams and community. It is important to view AI not as a single kid because AI consists of multiple LLMs and harnesses.

Therefore, our immediate expectation when working with AI is that there is no single way to prepare for or interact with AI that always works across all AIs. The inconsistency and unpredictability of the current state of AI, and how it impacts our work, is making people anxious, which is leading them to want tools and processes to prepare to collaborate with AI. I'm writing this post because I think people's anxiety about AI is making them overprepare.

Overpreparing for AI

A large part of the AI narrative centers on the tooling you need to use AI. I feel that most of the AI tooling is overbuilt or overplanned. At the same time, harnesses like OpenCode provide essential tools and methodologies for an LLM to write code and perform tasks. Still, a harness is just a tool for AI, like the computer and software I am using to write this post.

The tooling and planning I am concerned about involve AI-specific processes for managing and orchestrating AI agents. Many people in the software community are developing AI best practices to address the challenge of integrating AI into our software development process.

A quick aside. I think having AI best practices for Drupal as a collaborative, community-led initiative is essential to Drupal's proper adoption of agent-driven development. Before someone starts using Drupal's AI best practices, they should understand what AI is.

What exactly is AI?

I don't know...Read More

Back in 2019, I wrote that Open Source is not a meritocracy. Meritocracy says talent is the only thing that counts, but that is not true. To contribute, you also need time, a steady income, and a flexible schedule. Plenty of people lack one or more of these.

Some people can give their nights and weekends to learning a codebase, clearing the issue queue, or reviewing patches. Some are paid to do it on the clock. A lot of people can't do either. Their hours go to a second job, caring for family, or simply making it through the week.

That doesn't make these people less talented. It means they have less opportunity.

AI changes that math. A contributor might have the skill to fix a bug, but not the time to learn an unfamiliar codebase. AI can explain unfamiliar code and point them to where the fix belongs.

On paper, that should be great news for Open Source. In practice, AI will only help if access and skill become shared, not private advantages.

AI access is not equal. The most capable models and coding agents cost real money, and using them well takes real skill. I pay hundreds of dollars a month for these tools and have spent countless hours learning when to trust them, when to doubt them, and how to turn their output into useful work. Many contributors do not have that money or that time.

We learned once that "anyone can contribute" is not the same as "everyone has the same opportunity to contribute". AI can repeat that mistake in a new form.

Powerful technologies rarely share their benefits evenly at first. Electricity did not create equal opportunity the moment it was invented. It only changed lives broadly when people built the infrastructure to make it widely available.

The internet followed a similar path: it started with privileged access, then became useful to millions more people as infrastructure, tools, and skills spread.

AI is following the same pattern. It is powerful, imperfect, and unevenly distributed. We should not ban AI or pretend it has no flaws. If we want it to become broadly useful, more people need access to it and the knowledge to use it well.

If we want AI to reduce privilege in Open Source instead of reinforcing it, we have to close two gaps.

The first is cost. Contributors should be able to do meaningful work without paying for the most expensive AI tools. As lower-cost models, including open-weight models, improve, Open Source projects should make them practical for contribution work.

The second is skill. Knowing how to use AI well should become shared knowledge within Open Source projects so more people can learn faster and make better contributions.

Contributing with AI should come down to talent, not to who can afford the best tools or who has the time to learn them.

Open Source already moves many things from private advantage to shared infrastructure: code, documentation, test suites, best practices, decision-making processes, and even the financial side of our projects. The ability to use AI well for contribution should move in the same direction.

The opportunity is not just to make today's contributors faster. It is to help many more people become Open Source contributors: people with the talent, but not the free time, the insider knowledge, the employer backing, or the money for the best tools.

But more contribution is not automatically progress. As I wrote in AI creates asymmetric pressure on Open Source, AI can make it cheaper to contribute without making it cheaper to review.

The test is whether it helps more people move from issue to tested patch while making the result easier for maintainers to trust and merge.

If we do this well, AI can reduce the privilege of free time, insider knowledge, and expensive tools. If we do it poorly, it will widen the gap for contributors and increase the burden on maintainers.

In 2019, I argued that Open Source communities should create opportunity by paying contributors. I still believe that. Paying contributors gives people time. But AI gives us another way to reduce the privilege of free time: it helps people do more with the time they have.

I want Drupal to help explore what that looks like in practice: not because we have all the answers, but because this is the kind of problem Open Source should help solve.

Drupal Canvas AI gives content teams prompt-based speed, along with governance and brand control. Here is what it does and how to use it.

Plenty of clients arrive with a system they see as a line item to keep cheap. The real job of an agency is to help them see what that same system could become - and why it is worth investing in.

See how a Drupal development partner relationship grows from minimal support into strategic investment - five readiness signals, quick wins that prove value, the account growth curve, and a ~24% conversion lift on one real account.

Today we are talking about Marketing, AI, and Drupal with guest Paul Johnson. We'll also cover Curated Colors as our module of the week.

For show notes visit: https://www.talkingDrupal.com/559

Topics

• Paul's Current Projects
• Enterprise AI Summit Details
• Marketing the AI Initiative
• Partnering on Event Booths
• Drupal's Outside Perception
• What's Working Now
• Growing the Marketing Team
• How to Contribute
• Outside In Storytelling
• Case Study Examples
• AI Initiative Impact
• Roadmap and Launch Planning
• Finding New Adopters
• Where Pros Research
• Conference Pitch Story
• Local Event Playbook
• Funnel and Webinars
• Industry Guides and Demos
• SEO and AI Search
• Why Agents Avoid Drupal
• High Leverage Contributions
• Measuring AI Mentions
• Vibe Coders to Governance
• Fixing Misconceptions

Resources

• Drupal AI Initiative home page
• Slack
  • #ai-initiative-marketing
• Enterprise AI Summit Rotterdam
• AI Dev Summit Rotterdam
• Drupal AI TV
  • We've curated a selection of the best presentations, workshops and demonstrations freely available to provide a practical way to stay informed about the latest innovations in Drupal AI.
• Drupal AI Webinars playlist
• Demos
• Ryan Whitcombe
• 1xINTERNET S1xSignals free AIO GEO assessment
• All things open
• World cancer day

Guests

Paul Johnson - pdjohnson

Hosts

Nic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Scott Falconer - managing-ai.com scott-falconer

MOTW Correspondent

Martin Anderson-Clutz - mandclu.com mandclu

• Brief description:
  • Have you ever wanted to allow editors on your Drupal site to choose styling from a brand-approved color palette? There's a module for that.
• Module name/project name:
  • Curated Colors
• Brief history
  • How old: created in Apr 2026 by Kyle Einecker (ctrladel) of True Summit
  • Versions available: 1.0.0 which works with Drupal 10.3, 11, and 12
• Maintainership
  • Actively maintained
  • Security coverage
  • Test coverage
  • Documentation - in-depth README
  • Number of open issues: 2 open issues, neither of which are bugs
• Usage stats:
  • 27 sites
• Module features and usage
  • Curated Colors enforces brand consistency by replacing generic color text inputs or wide-open color pickers with a curated, visual swatch popover containing only pre-approved, named options
  • It streamlines rebranding by storing abstract keys (such as brand-primary) instead of raw hex values (e.g., #0678be) in the database. That means updating a brand color in the future only requires a CSS or configuration change rather than a massive data migration
  • Curated Colors is also extensible beyond colors. It functions as a generic visual variant selector. Site builders can repurpose it to let editors pick card layouts, button styles (like primary, outline, or danger), hero text alignments, or icon themes
  • Editors can pick from neatly organized groups with human-readable labels and see a live preview swatch of their selection before saving
  • Palettes are managed as exportable Drupal configuration. Each entry maps a machine key to a label, administrative hex preview, and optional custom CSS
  • The module provides a curated_color field type and an accompanying swatch-based popover widget that can be restricted to specific palette groups. It also features a native curated_color_picker Form API element and integrates with the Canvas module via SDC annotations
  • The field exposes properties like value, hex, style, and css, making it simple to output selections as classes, inline styles, or raw codes in Twig templates
  • Finally, Curated Colors includes an example submodule providing a working SDC component and sample palette templates so you can see exactly how it's meant to be used

A full rebuild feels like progress. More often it is the most expensive, slowest, and riskiest way to solve a problem that proper implementation would fix in a fraction of the time.

A phased CMS modernization framework for CTOs and marketing leaders: true rebuild costs, when starting fresh is justified, four evolution phases, a decision checklist, and how to sell incremental change to stakeholders.

We used our own plugins and skills to rebuild our site, here is the story Imagen We pointed the plugins and skills we built ourselves at our own site, and rebuilt the whole thing, brand and all, in about a week of supervised time. Here is what that was actually like: what the tools did well, where they were confidently wrong, and where a human had to step in. These tools will hand you something that looks finished, and whether it is actually good is a separate question. Holding those two together turned out to be the part we could not hand off. Imagen Carlos Ospina · Technical Account Manager / Drupal Advisor Imagen Ana Coto · Senior Web Developer Mon, 06/29/2026 - 10:57 Drupal Drupal Planet AI theming Human-in-the-Loop DaisyUI design system accessibility Add new comment

Artificial intelligence is posing a practical question to Drupal. If AI agents can help plan, build, inspect, and change websites, how easily can they work with Drupal when faster platforms are easier to start?

The Drupal AI Initiative made that question more explicit on 25 June 2026, when it split its work into two streams: Inside AI and Outside AI. Inside AI focuses on tools used within Drupal, including assistants, page-building, and in-product workflows. Outside AI focuses on agents and external tools that need to start with Drupal, connect to it, inspect it, change it, verify it, migrate into it, or launch it.

The shift matters because AI changes how platform choices are made. Human teams may choose Drupal for structured content, permissions, workflows, revisions, and long-term governance. An AI coding agent may judge the same platform by a shorter test: whether it can install, configure, understand, and verify a working site in one session.

Dries Buytaert tested that tension directly when he asked an AI coding agent whether it would recommend Drupal for a site-building task. The agent ranked Drupal third, behind a Next.js and headless CMS stack and WordPress. It did not say Drupal lacked capability. It said Drupal carried more “session-time risk” because setup, module selection, documentation, training data, and frontend choices made the first working session harder to complete confidently.

That is the useful problem for the community to address. Drupal’s AI work cannot depend only on adding visible AI features inside the CMS. It also has to make Drupal easier for external agents and agent-assisted developers to understand, call, inspect, and modify without losing the controls that make the platform valuable.

TDT has also covered this from the workflow side. A report on Drupal orchestration primitives looked at how ECA, FlowDrop, Maestro, and Drupal core are being discussed through shared workflow terms such as triggers, steps, conditions, workflows, and runs. The unresolved question is data handoff: how work moves between Drupal tools, across workflow systems, and out to agents or external automation without breaking governance.

This is where Drupal’s older strengths may become newly important. Revisions, moderation states, permissions, access control, structured content, multilingual architecture, and publishing review are not only CMS features. They are the controls that external AI systems may need when generated content, configuration changes, or workflow actions have to be checked before they reach production.

The test for Outside AI will not be the terminology. It will be about whether Drupal can reduce first-session friction that leads agents to choose simpler tools, while still giving organisations control over review, rollback, audit, and publishing. That means clearer documentation, faster setup paths, reliable examples, machine-readable interfaces, and real feedback from agencies and developers using AI in delivery work.

The curated story list for this edition follows the editor’s note. Readers can also follow The Drop Times on LinkedIn, Twitter, Bluesky, and Facebook, or join the publication’s Drupal Slack channel at #thedroptimes.

Kazima Abbas
Sub-editor
The Drop Times

The last remaining reason to compile your CSS has just disappeared.

CSS Style Queries have reached Baseline support across all major browsers, and they unlock something we've wanted for years: reusable, stateful design tokens that work entirely in native CSS.

The syntax

At its most basic, style queries allow you to add CSS rules to a nested element, based on a parent’s CSS variable.

Our 36th monthly UI Suite meeting (June 18, 2026) was a packed one. Despite the early-summer heat in Paris and a few people already on holiday, the team walked through a string of releases, demoed a brand-new starter kit, and gave a first live look at AI agents building Drupal pages on their own. Here's everything that happened.

For Drupal teams, emerging tools now touch page building, editing expectations, translation consistency, hosting choices, and debt management. Kortrijk speakers place those shifts inside practical project decisions.

Drupal’s workflow tools are being described less as rivals and more as complementary layers. The open question is whether shared primitives can make them compose safely for AI-driven and human-reviewed work.

Earlier this week, in "Drupal's role in agentic workflows", I argued that Drupal's AI future has two parts: helping people with AI inside Drupal, and helping agents use Drupal from the outside.

So we are splitting Drupal's AI strategy into two workstreams. Inside AI is led by Christoph Breidert, who has been driving that work already. Outside AI, the new workstream, is led by Scott Falconer.

The easiest way to think about the difference: 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 launched the Drupal AI Initiative one year ago, in June 2025, with a published strategy. A year later it spans 32 organizations and more than 50 contributors, shipping against a public 2026 roadmap through two paid delivery teams.

So far, most of that work has focused on Inside AI, though much of the foundation also supports Outside AI.

Outside AI will serve three kinds of users:

• Developers new to Drupal. They ask an AI agent to build a website, and the agent chooses what to build on. Agents reach for whatever they can spin up in seconds, so the opportunity is to make Drupal that easy to install, configure, and use.
• Experienced Drupal developers. They already know Drupal is the right tool, and they want agents to take on more of the work. For Drupal agencies, Outside AI should turn AI into a stronger advantage: helping teams move faster, win more work, protect profitability, and get more value from their Drupal talent.
• External agentic systems and workflow automation tools. These systems coordinate work across many tools, but when they touch content, they need a trusted system of record for workflows, permissions, revisions, and publishing. Rather than rebuilding that governance elsewhere, they should call into Drupal.

If we are successful, agents will recommend Drupal to new users, help Drupal developers move faster, help agencies win more work, and use Drupal as the trusted layer for content management and governance.

Thank you to everyone who helped bring the Drupal AI Initiative to this point. Together, the community has turned an ambitious idea into real momentum.

I'm excited about what comes next! Want to get involved? Join the #ai-initiative channel on Drupal Slack.

By the Drupal AI Initiative

A year ago, we launched the Drupal AI Initiative with a published strategy and a bet that AI would matter enormously to Drupal's future. Today the initiative spans 32 organizations and more than 50 contributors, shipping against a public 2026 roadmap.

As the work has grown, it's become clear that our AI strategy needs to cover two distinct areas. While innovation and product development remain core goals across everything we do, we are organizing our day-to-day execution into two workstreams: Inside AI, led by Christoph Breidert, and Outside AI, a new stream led by Scott Falconer. 

The unified AI initiative leadership team - made up of the existing initiative members - will continue to shape our overarching roadmap, while Christoph and Scott ensure that vision is executed. We will outline this leadership team and other key supporting roles in an upcoming post.

The core difference: Inside AI brings AI tools into the Drupal interface to assist the people using it. Outside AI makes Drupal the platform external AI agents reach for and act on.

Inside AI

Inside AI is AI inside Drupal, for the people using it: assistants, in-product workflows, page-building, and the rest of the user-facing surface. This is the work the initiative has been driving for the past year, and it continues against the 2026 roadmap already in flight.

Outside AI

Outside AI is AI outside Drupal, acting on Drupal. A person, agency, host, or developer is using an external agent or builder tool, and that agent needs to start with Drupal, connect to Drupal, inspect Drupal, change Drupal, verify Drupal, migrate into Drupal, or launch Drupal. 

What's next

You'll see public roadmaps from both streams. Inside AI continues against its existing 2026 roadmap; Outside AI will publish its own outcomes and milestones, with a first proof of direction targeted for DrupalCon Rotterdam. Where both streams need the same capability, the answer is usually one shared Drupal contribution, not two parallel builds.

Get involved

The initiative is open, and both streams need contributors  -  whether you write code, test against real agent workflows, work on documentation, or bring a use case from your own agency or organization.

• Read the strategy and the public 2026 roadmap to see where each stream is headed.
• Collaborate with our partners to deliver the latest AI features to your users.
• Become an AI Partner.
• Join the conversation in the #ai-initiative channel on Drupal Slack.
• Check the issue queues for Inside AI and Outside AI work, and pick something up.

Not sure where to start? Come say hello in Slack and we'll help you find a first contribution.
 

For Drupal teams, small technical choices often decide how maintainable a site becomes. DrupalCamp Kortrijk speakers are using that practical layer as the entry point for sessions on configuration, performance, CSS and editorial work.

Maintainer burnout threatens Drupal's 50,000+ contrib modules. How vibe coding with AI is becoming a lifeline for open source.

When a CMS is too hard to use, teams paste text into graphics and upload them as images. The page looks right - but search engines and AI answer engines cannot read that content at all.

See what image-based content costs you in SEO, GEO, accessibility, and day-to-day management - and how structured Drupal components fix it page by page.

Three Players, One Direction: ECA, FlowDrop, and Maestro Jürgen Haas Thu 25 Jun 2026 - 13:00

ECA, FlowDrop, and Maestro all draw boxes and connect them with arrows, so people keep asking whether three Drupal workflow modules means a split community. Not quite. Dries Buytaert, Randy Kolenko, Shibin Das, and I are writing a shared orchestration design spec, disagreeing productively in writing. One axis explains all three: how much state a run carries. ECA reacts statelessly to any Drupal event across the whole request surface. Maestro holds a durable process that can wait days for human approval. FlowDrop spans the axis with a typed, inspectable dataflow graph that runs sync, async, or stateful from one definition, and Shibin is refining it toward strictly serializable data, ideal for building complex AI agents. Nothing is frozen. The word "orchestration" itself is contested in the spec glossary. Composition already ships: maestro_eca_task lets a Maestro process hand off to ECA. The bigger vision, ECA reacting to content, calling a FlowDrop AI flow, then routing through Maestro for human approval, is a picture we are building toward, not a release. But bridges are the start, not the finish. The real work is building a shared foundation, common primitives and APIs so the three tools stop reinventing the same concepts under different names. The spec's vocabulary synthesis shows the embarrassing similarity: Trigger, Step, Condition, Workflow, Run. The keystone is a defined contract for handing data between steps and between tools, one that works beyond Drupal's border for AI agents and external systems. Three tools is the right number because the stateless-reactive and instance-stateful ends pull architectures in opposite directions. Specialization beats a mediocre merger.