Drupal AI is production-ready. Its AI agents are not.
“We want AI in our Drupal site” is now a sentence I hear in most discovery calls. It is also two completely different requests wearing the same words, and the gap between them is the difference between a feature you can ship next sprint and one the project itself tells you not to deploy.
Here is the boundary, with the project pages as evidence.
The AI module is real, and you can use it today
Drupal AI is not a weekend experiment. As I write this it reports 23,475 installs — up from roughly 14,000 in April, so it has grown by two thirds in six months. The latest stable release, 1.5.0, shipped on September 25, 2026, and the project carries stable release security coverage from the Drupal Security Team. That last detail is the one that matters in an enterprise procurement conversation, and it is the one nobody mentions in the hype posts.
What ships inside it is a framework plus a set of assistive submodules: AI Core, AI Automators, AI CKEditor, AI Translate, AI Search, AI Content Suggestions, AI Assistants, AI Chatbot, AI Validations, AI Logging and AI Observability, among others.
Notice the shape of that list. Almost all of it is assistive: a human asks for something, the model proposes, the human accepts or rejects. Translation drafts. Alt-text suggestions. Editor-side help in CKEditor. Smarter search. These fit an editorial workflow because they slot into a step a person was already performing.
That is a genuinely useful product, and if a client asks for “AI in Drupal” this is almost always what they actually need.
The agents are a different thing entirely
What people usually picture, though, is agents: software that takes a goal and acts on the site by itself.
The AI Agents Experimental Collection was created in March 2026. Read its own project page before you read anyone’s opinion of it, including mine. Three things it says about itself:
- “Do not use this in production — these agents are not production-ready and may produce unexpected results.”
- It is not covered by Drupal’s security advisory policy.
- The entire codebase was written by coding agents and has not been through a full human review process.
I want to be fair about what that is. It is not a failure, and the maintainers deserve credit for stating it that plainly rather than burying it. It is an explicitly labelled playground, with a published promotion path: any agent judged ready gets moved out of the collection into its own module and human-reviewed first. That is exactly how this should work.
But it does mean the honest answer to “can we put Drupal AI agents on our platform?” is no, and the project agrees with me.
Why the distinction gets expensive
The reason this matters more on an editorial platform than on a brochure site is governance, not capability.
I spend my working days in editorial back offices — the kind where a newsroom publishes around the clock and every change is attributable to a person. Drop an autonomous agent into that and the hard questions are not about the model:
- Who is the author? Your workflow assumes a
uidbehind every revision. An agent is not a person, and your audit trail was not designed for one. - What are its permissions? Agents inherit an account. An agent with an editor role can do anything an editor can, including at 3am with nobody watching.
- How do you review a batch? One suggestion a human accepts is reviewable. Four hundred overnight edits is a different problem, and your moderation UI was built for the first case.
- How do you roll back? Not one node — a whole run.
Note what Dries’ 2026 AI roadmap lists among its eight capabilities: “Advanced governance — batch approvals, branch-based versioning, and comprehensive audit trails for AI changes.” The initiative knows. Governance is on the roadmap precisely because autonomous editing is unshippable to serious organisations without it.
That roadmap, incidentally, is not a wish list: 28 organisations and more than 23 full-time-equivalent contributors are behind it. This is the best-resourced thing happening in Drupal right now.
What I would actually do
If you run a Drupal platform and want to act on this in October 2026:
- Install the AI module and turn on the assistive pieces. AI Translate and AI CKEditor pay for themselves fast on multilingual editorial sites, and nothing autonomous happens.
- Give it a real provider budget and a logging policy. AI Logging and AI Observability exist for a reason; turn them on before your editors do, not after the invoice arrives.
- Put agents in staging, on a content copy, and never on production. Treat the experimental collection as a research tool — which is what its maintainers call it.
- Make governance your acceptance criterion. When a vendor pitches you autonomous content agents, ask who the revision author is, how a run is reviewed, and how it is rolled back. If there is no answer, the product is not finished regardless of how the demo looks.
The useful split: assistive AI is a 2026 decision, autonomous AI is a 2027 one. Everything in the first bucket is shippable now and most of the value is there anyway, because the bottleneck in an editorial team was never the typing.
Deciding what AI actually belongs in your Drupal platform — and what to refuse? That conversation is part of the development and architecture work I do, usually starting with the governance questions above rather than the model.