Drupal AI 1.5.0 Splits Into Standalone Projects: What Your Upgrade Path Looks Like

The Drupal AI module has been moving fast, and 1.5.0 just introduced the kind of structural change that can quietly break a site if you update without reading the release notes first. Five submodules that previously shipped inside the main AI package are now independent projects on drupal.org, and the migration paths vary depending on which features you are currently using.

What changed in Drupal AI 1.5.0

Up through 1.4.x, the Drupal AI module was essentially a monorepo: one package, many bundled submodules covering everything from provider integrations to content generation helpers and agent tooling. The 1.5.0 release extracts five of those submodules into their own standalone projects.

The reasoning from the maintainers is sound. Bundled submodules create a coordination problem: the release cycle of the whole package gets held hostage to the readiness of every individual feature. By splitting them out, each project can ship fixes and improvements on its own schedule, have its own issue queue, and be maintained by contributors who specialize in that area rather than needing commit access to the entire AI module.

In practice, this means:

• Five submodules now live at separate drupal.org project pages, with their own version numbers and release histories.
• Existing installations do not automatically migrate. If you had a submodule enabled via the AI package, you need to explicitly require the new standalone project via Composer and enable it before removing the old path.
• The next minor release (1.6.0) is where things get particularly important. According to the release notes, 1.6.0 will formally drop the bundled copies of these submodules entirely. Sites that skip straight from 1.4.x to 1.6.x without going through the 1.5.0 transition step will lose functionality without an obvious error message explaining why.
• Dependencies between the new standalone projects and the AI core module are versioned, so Composer's constraint resolver should catch obvious mismatches, but only if your composer.json is explicit about which submodules you need.

The submodules affected cover a range of functionality including provider integrations and agent-layer tooling, the exact five are detailed in the linked release announcement.

Our take

We have been running the Drupal AI module in production on a handful of client sites since the 1.x stable series landed, and our honest read on this split is: it is the right architectural call made at an awkward moment in the module's maturity curve.

The monorepo approach made sense when the project was moving at prototype speed and the maintainers needed to ship coherent slices of functionality without managing a web of inter-project dependencies. Now that AI features are landing in real editorial workflows and clients are actually using them, the coordination overhead of a bundled release cycle becomes a real cost. A bug in the content generation helper should not block a patch to the provider integration. Splitting solves that.

What it also does, though, is add update complexity for every agency or site owner who has already adopted the module. And unlike a typical Drupal core security advisory where the upgrade path is "run composer update drupal/core, clear cache, done," this one requires you to audit which submodules you are using, add new Composer requirements, verify the new standalone modules enable correctly, and only then remove the old paths. That is a 1-2 hour task on a simple site and a half-day engagement on a complex one with custom code that hooks into the AI module's APIs.

Here is where it gets easy to make a mistake: the 1.5.0 release keeps the bundled submodule code in place as a transitional shim. That shim is gone in 1.6.0. This is good practice from the maintainers but it creates a false sense of safety. A site that updates to 1.5.0 and sees no breakage may update to 1.6.0 six weeks later and suddenly have missing functionality. We have seen this pattern with other Drupal module splits over the years, and it catches teams who treat minor version updates as routine.

Our recommendation is to treat 1.5.0 as a migration release, not a feature release, and handle the submodule transition deliberately rather than deferring it.

One broader point worth making: this split reflects where Drupal AI as a project is headed. The module is no longer a single team's experiment. Multiple contributors are working on distinct pieces of the AI layer, and decoupling the release cadence is what allows that kind of distributed contribution to work. For agencies building on Drupal AI, the practical implication is that you should start tracking the relevant standalone projects separately in your Composer files and your update monitoring workflows, rather than watching only the parent package.

Practical steps for sites running Drupal AI

1. Audit your enabled submodules before touching 1.5.0. Run drush pm:list --status=enabled and note every AI-prefixed module currently active.
2. Check the 1.5.0 release notes for the exact list of five submodules that have been extracted and their new drupal.org project URLs.
3. Add the new standalone projects to your composer.json explicitly: composer require drupal/<new-project-name> for each one you need.
4. Enable the new standalone modules and confirm functionality on a staging environment before touching production.
5. Remove the old bundled submodule dependencies only after verifying the standalone versions are working.
6. Pin your AI module version to ^1.5 in composer.json until you have completed and tested the full migration, then allow the upgrade to 1.6.0 in a controlled window.
7. Update your monitoring. If you are using Renovate, Dependabot, or a manual Composer audit process, add the new standalone project names to your watchlist.

For sites with custom modules that implement hooks or call services from the AI submodules being split, budget extra time for a code audit. API namespaces may shift between the bundled and standalone versions.

Originally referenced: Drupal AI 1.5.0 Moves Five Submodules Into Standalone Projects on The Drop Times.

If you are running Drupal AI in production and want a hand planning the 1.5.0 migration before 1.6.0 drops the bundled shims, get in touch. This is exactly the kind of update that looks routine in the changelog and bites you three weeks later if the transition is skipped.