fidzu : Drupal

Image Credit: Mike Gifford

I spent last week at the UN in New York for Open Source Week. The AI sessions were sharp, well-attended, and full of people who have been thinking seriously about where this is all going. Ministers, engineers, researchers, cybersecurity practitioners.

And across four days of sessions, a picture kept assembling itself - not one anyone drew deliberately, but one that emerged from enough different people making enough adjacent points. By the end of the week I was fairly convinced that what the AI world is urgently trying to build, Drupal already is.

Read on and let me make the case.

The model is not the thing

Brian Behlendorf said it plainly: people talk about AI as if it's the model. It isn't. The model is one layer. What matters is the harness. How you orchestrate models, constrain them, route information, log outputs, build verification in. That's where the work happens. That's where the risk lives and where we create value.

Sara Hooker from Adaptation Labs made the same point from a different angle. We used to work in code and design. Interfaces were understood and boundaries were mostly clear. AI has moved us into unknown interfaces. The next step, she said, is dynamic, adaptable interfaces that allow humans to remain at the centre. Not interfaces that hand control to the model, but ones that keep the human in the loop while the model does the work.

I've been saying that Drupal has quietly become the most flexible and powerful AI harness available. This week gave me a room full of smart people explaining which helped bring that conviction into focus.

What a harness needs to do

Let me pull a few threads from the week.

It needs to constrain the model to known truth. One of the most interesting presentations came from a team that deployed a chatbot for Pittsburgh's Public Works department. The very first question from city officials was: "How do we know the answer is correct?" Their solution was a Data Concierge model - the AI is only permitted to answer questions against a defined dataset. If it can't answer from the data, it doesn't answer; the question goes into a queue. This makes the AI responses reproducible, traceable, and auditable.

That is what Drupal can do when you integrate AI into a content management workflow. The model doesn't get to hallucinate about your organisation's policies. It answers from what you've published, structured, and governed. The content model is the constraint.

It needs to aggregate intelligence, not just query a single model. Mostafa Elkordy from UNICC put this as clearly as anyone: every agent in isolation only has its own memory. The most critical and least understood capability in enterprise AI is intelligence harnessing. We need to pull all intelligence sources into a single coherent system. The organisations that figure this out will have a structural advantage. The ones that treat AI as a chat widget bolted onto a webpage will not.

Drupal's architecture is built for this. You have multiple data sources, multiple content types, relationships between entities, and views that aggregate and filter. This is what structured content management systems do best. Adding AI to that foundation is a multiplier. Adding AI to an unstructured system makes a mess.

It needs to keep humans in control, not in the dark.

Rodrigo Rodríguez, an AI & Quantum Architect at Microsoft made a point early in the week that I keep coming back to: AI is clustered around organised confidence. It rarely says "I don't know." Confidence is not evidence. The harness is the mechanism by which you decide what the AI is allowed to be confident about, and when it should surface uncertainty rather than paper over it.

Drupal's editorial workflows, content moderation, and publishing controls are part of a governance layer that sits between AI output and public consumption. A model can draft. A human approves. That's not a limitation. In fact, that's the architecture working as intended.

The verification problem

Tricia Wang made the argument I found most compelling across the entire week. We live in a claims-based AI world. A model asserts something is true. You have no mechanism to verify it independently. She called for a move to a verification-based world - ideally cryptographic - where claims can be checked against sources without exposing the underlying data.

She also made an observation that seemed obvious once she said it: we trust agents all the time. Every time you board a plane, you're trusting an agentic system - pilots, air traffic controllers, flight management software. We know how to govern this. We have liability frameworks, certification requirements, black boxes, independent investigation bodies. We just haven't built any of that for AI yet.

What Drupal offers in this space is structural transparency. Content has provenance. You can see who created it, when, what revision it's on, what workflow state it passed through. When AI is integrated into that system, the AI's contributions can be logged, reviewed, and attributed in the same way. That's the beginning of a verifiable AI layer - not cryptographic yet, but architecturally honest in a way that most AI deployments are not.

The zero-day exploit window is now down to seven days, according to Jim Zemlin from the Linux Foundation. In 2020 it was sixty. The security argument for keeping AI tightly integrated with auditable, open-source infrastructure isn't a theory. It is a requirement.

The sovereignty argument

David Shrier from Imperial College described intelligence as the next sovereign battlefield. The concentration of AI capability inside roughly eight companies is a structural problem. Hyperscalers are, in effect, concentrations of intelligence. Open source is the mechanism for distributing that intelligence more broadly.

Tanzania's Minister of Technology put it in terms I found more useful: her government is no longer a passive consumer of technology. It's an active creator. 90% of government systems are on open source. The savings from licence elimination have been reinvested in people. The workforce now owns the systems it builds.

The Drupal parallel is direct. When you run AI on Drupal, you're running it on infrastructure no single vendor controls. The model can be swapped. The hosting can be changed. The data stays yours. This is not a minor point - the lock-in risk in AI is real, and it's coming fast. The organisations building AI on proprietary stacks are creating dependencies they will spend years trying to unwind.

Morocco is building a 1 GW data centre and training 100,000 people a year in digital skills, specifically so it can run sovereign AI infrastructure with local values embedded. That's "open source as an instrument of sovereignty" at national scale. The same logic can apply at the organisational level.

The governance argument

The DPI sessions drove home a point that applies directly to AI: the technical system is rarely the problem. The governance is. Ethiopia has 98% ID coverage and 92% payment wallet adoption - and yet fewer than 5% of people can actually access the protections those systems are supposed to provide. The technology works but the governance doesn't.

Armando Manzueta from the Dominican Republic put it cleanly: treat AI with the same governance rigour as your core infrastructure. Without proper guardrails and oversight, you shouldn't do it at all. Human oversight must be embedded so mistakes can be corrected in real time.

This is an argument Drupal has been making implicitly for twenty-five years. Content governance - who can publish what, when, through what process - is the foundational problem that Drupal was built to solve. The workflows, roles, permissions, and moderation tools are a governance system for information. Extending that to AI output is not a conceptual leap. It just extends what Drupal already does.

The Premise

Here is the argument in full: the AI conversation at the UN kept arriving at the same destination from different directions. You need a harness, not just models. The harness needs to constrain the model to verified data. It needs to aggregate intelligence across sources. It needs human oversight and editorial control. It needs to be open source so it can be audited, forked, and owned. It needs governance built into the architecture, not bolted on afterwards.

What does that remind you of? Drupal with AI integration.

The Drupal work isn't finished. The AI modules aren't mature yet. The work won't be easy. I'm suggesting that the architectural foundation is right, and the architectural foundation is the hardest part. Most organisations are trying to build AI workflows on systems that weren't designed for governance, structured content, or auditability. They're going to spend a lot of time and money discovering what the DPI world learned the hard way: the technology problem is tractable. The governance problem is where things break. Our community even has a Road Map that describes many of these challenges.

Drupal solved the governance problem for content a long time ago. That foundation is now worth something more than it was worth two years ago.

---

Matthew Saunders works in AI and open-source infrastructure at amazee.io and has been building on Drupal since 2006.

01 Jul 2026 3:18pm GMT

My LocalGov Drupal contributions for June 2026

markconroy 1st Jul 2026

01 Jul 2026 11:20am GMT

The ECA Guide Revolution: Documentation Meets AI

Jürgen Haas Wed 1 Jul 2026 - 12:00

01 Jul 2026 10:00am GMT

30 Jun 2026 7:59pm GMT

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

30 Jun 2026 3:33pm GMT

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

30 Jun 2026 3:13pm GMT

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.

30 Jun 2026 2:41pm GMT

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.

30 Jun 2026 11:21am GMT

More than a dozen Drupal site templates are available. Compare every marketplace option by sector, design system, and content architecture.

30 Jun 2026 8:13am GMT

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.

29 Jun 2026 6:38pm GMT

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

29 Jun 2026 6:00pm GMT

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.

29 Jun 2026 5:47pm GMT

Imagen

Imagen

Carlos

Ospina

·

Technical Account Manager / Drupal Advisor

Imagen

Ana

Coto

·

Senior Web Developer

29 Jun 2026 3:57pm GMT

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

29 Jun 2026 3:31pm GMT

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.

29 Jun 2026 12:29pm GMT

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.

29 Jun 2026 9:30am GMT