The Drupal AI module ecosystem, mapped
Choosing Drupal AI modules starts with a practical question: which task will save your team time without creating more work elsewhere? This Drupal AI modules overview maps the available building blocks, their release status, dependencies, and operating costs so you can narrow your shortlist.
There’s a distinction to keep in mind. Helping editors summarize content is different from letting an external agent change that content. Semantic search brings another set of dependencies and expenses.
The ecosystem supports all these directions, but its components have different levels of maturity. This snapshot covers releases listed through October 13, 2026, rather than the remainder of the month. Release listings establish availability, not hands-on compatibility or suitability for your website.
As of October 2026. Sources last checked: October 13, 2026.
In this article:
- Start with the architecture, not the module list
- The Drupal AI ecosystem at a glance
- Editorial assistance: keep editors in control
- Automation: remove repetitive steps carefully
- Search and retrieval: budget for the whole pipeline
- Translation: separate draft generation from approval
- Agents, context, and external access
- Package changes that affect upgrades
- Provider configuration and cost control
- What is ready for production evaluation?
- Which components matter for this series?
Start with the architecture, not the module list
You can avoid unnecessary dependencies by separating the ecosystem into layers.
The AI framework provides shared foundations and provider abstraction. Provider integrations connect Drupal to models and services. Feature modules add specific capabilities, such as translation or suggestions in editing forms.
Recipes package configuration for a particular setup. They can help you get started, but their names don’t tell you whether every underlying dependency has a stable release.
External-agent integrations serve a different purpose: they expose Drupal capabilities to software operating outside the website.
The Drupal AI initiative describes this distinction as Inside AI and Outside AI:
- Inside AI: people use AI within Drupal interfaces and workflows.
- Outside AI: external AI clients interact with Drupal through exposed capabilities.
These layers build on Drupal’s existing strengths. Fields, entities, taxonomies, and language metadata give content a consistent structure. JSON:API, structured data, and other output formats can make that information available to machines. We cover field-first modeling in Drupal content modeling for answer coverage: fields, not prose.
Installing an AI module doesn’t automatically make a website easier for AI assistants to understand. Clear content models and reliable publishing practices still do much of that work.
The Drupal AI ecosystem at a glance
Use this table to identify candidates, then inspect the selected release and its dependencies before installation.
Read also: Drupal AI: how to create website content using Drupal AI modules? for a hands-on editorial starting point.
“Stable” describes a published release. Security-advisory coverage and suitability for your deployment need separate checks. Dependency notes below identify major building blocks, not complete Composer requirements. “Verify” means the research snapshot did not record a Drupal core constraint.
| Module | Job | Release & core | Dependencies & cost |
|---|---|---|---|
| AI framework | Shared AI foundation and provider abstraction | 1.5.0 stable; 2.0 development branch Core: ^10.5 or ^11.2 | Provider integration and credentials for the chosen operations Run cost: Provider requests or self-hosted model infrastructure; integration upkeep |
| AI Automators, within the AI framework | Automated AI processing, including field-oriented workflows | Framework submodule; assess within the selected AI release Core: Follow the selected framework release | Framework, configured provider, relevant workflow configuration Run cost: Calls per item, chained operations, retries, and bulk processing |
| AI Content Suggestions | Suggestions within editing forms | 1.5.2 stable; 1.6.0-alpha2 also available Core: Verify | AI framework and configured provider; check release requirements Run cost: Suggestions per editing session, prompt size, and generated output |
| AI Content Review | Configurable reviews, recorded results, and suggested changes | 1.0.0-alpha3; no supported stable release Core: ^10.5 or ^11.2 | AI ^1.3, Entity API ^1.6; default agent-based criterion also needs AI Agents ^1.2 and a providerRun cost: Review criteria, content length, repeat reviews, and agent calls |
| AI Image Alt Text | Generate image alt-text suggestions | 1.0.3 stable Core: ^10.2 or ^11 | Configured image-capable provider; verify selected release dependencies Run cost: Image processing requests and human review |
| AI Integration - ECA | AI steps in event/condition/action workflows | 1.0.1 stable Core: Verify | ECA, AI framework, and relevant provider configuration Run cost: Event frequency, actions per event, retries, and queues |
| AI Search | Search API integration, embeddings, vector search, and retrieval-augmented generation | 2.0.0-alpha2 and 1.3.0-alpha5; no supported stable release Core: Verify by branch | Search API and the embedding/vector integrations used by the chosen setup Run cost: Initial indexing, reindexing, vector storage, retrieval, and answer generation |
| AI Translate | Translate content through configured AI providers | 1.4.2 stable; 2.0 development described as pre-alpha Core: ^10.4 or ^11 | AI framework, provider, and relevant Drupal translation configuration Run cost: Source volume, target languages, regeneration, and language review |
| AI Agents | Tool-calling agents working with Drupal content or configuration | 1.3.5 stable; 1.4.0-beta1 also available Core: ^10.3 or ^11 | AI framework, suitable provider, and tools needed for the task Run cost: Multi-step model calls, tool execution, retries, and monitoring |
| AI Dashboard | Configuration and feature discovery | 1.0.3 stable Core: ^10.4 or ^11.1 | Verify requirements for the selected release and features Run cost: Setup and maintenance; costs of features enabled through it |
| AI Metering | Usage tracking, cost estimates, and quotas | 1.0.2 stable Core: ^10.5 or ^11.2 | Verify coverage for the framework, providers, and request paths you use Run cost: Logging, storage, maintenance, and configuration |
| Context Control Center | Manage organizational context for AI | 1.0.0-rc1; no supported stable release Core: Verify | Relevant AI integrations and context configuration Run cost: Maintaining context and sending it with requests |
| Tool API | Define reusable Drupal capabilities for different callers | 1.0.0-beta11; no supported stable release Core: Verify | Implementations of the tools you expose Run cost: Tool execution, access checks, maintenance, and caller-related costs |
| MCP Server | Expose Drupal capabilities to external AI clients | 2.0.0-beta5; no supported stable release Core: Verify | Compatible server/client setup and exposed capabilities; inspect branch requirements Run cost: Hosting, authentication, monitoring, tool execution, and client-side model usage |
Core compatibility alone won’t settle the installation question. A module may support an older Drupal version while another dependency in your selected stack requires a newer one.
Also check the release source. The AI Dashboard ecosystem directory is useful for discovery, but its inspected listing showed AI Agents 1.2.7 while the direct project page listed stable 1.3.5 and beta 1.4.0. Use project and release pages for version selection.
Editorial assistance: keep editors in control
Editorial assistance is often a manageable starting point because a person can review the output before publication. Keep the scope small.
AI Content Suggestions serves the editing moment: an editor requests a suggestion while working on content. AI Content Review supports a broader review process, with configurable criteria, recorded results, and suggested changes.
They serve different jobs. The Suggestions project directs review-workflow development toward Content Review, but that doesn’t mean Suggestions is abandoned. Their maturity also differs: Suggestions has a stable release in this snapshot; Content Review remains alpha.
Suppose your team wants help shortening summaries. An in-form suggestion may be enough. If the goal is to check every article against several editorial criteria and preserve the findings, evaluate a review workflow instead.
AI Image Alt Text addresses another repetitive task. Generated descriptions can give editors a starting point, but the surrounding page matters. An image might explain a process, link to another page, or serve only as decoration. The editor needs to judge its purpose before accepting the text.
For these use cases, preserve the original content and make acceptance explicit. Editors will spend less time correcting surprises when generation produces a draft rather than an immediate overwrite.
Automation: remove repetitive steps carefully
Automation offers larger time savings when teams repeat the same task across many records. It also multiplies mistakes and costs faster.
Two building blocks belong on the shortlist:
- AI Automators lives within the AI framework and supports automated processing.
- AI Integration - ECA brings AI steps into event/condition/action workflows.
Choose based on the workflow you need to express. A field-processing task and an event-driven sequence may need different configuration, even when both call the same model.
Suppose a content import needs draft summaries for articles that lack them. A bounded workflow will process only those records, save the result for review, and record failures. A workflow that runs on every save could repeatedly generate summaries and consume tokens.
Before a bulk run, decide what will trigger processing, what will count as completed work, and how editors will retry a failed item. Use a queue where appropriate, and test whether retrying a job can duplicate changes or provider calls.
Search and retrieval: budget for the whole pipeline
Search projects can consume more infrastructure and engineering time than the model call suggests.
AI Search connects several concerns: Search API, embeddings, vector search, and retrieval-augmented generation, often shortened to RAG. In a typical RAG workflow, the system retrieves relevant content and sends it to a model as context for an answer.
Each stage has its own cost:
- Prepare content: select fields, clean text, and split it into useful chunks.
- Create embeddings: process the initial collection and later changes.
- Store and retrieve vectors: operate the chosen backend.
- Generate answers: pay for prompts, retrieved context, and output.
- Maintain the index: handle updates, deletions, language changes, and access changes.
As of this snapshot, the standalone AI Search project has no supported stable release. Its alpha branches call for technical evaluation and a clear plan for handling change.
Start with the retrieval problem. If users need exact product codes or predictable filters, conventional Search API search may already meet the need. Semantic retrieval becomes more relevant when queries use different wording from the source material.
Access boundaries need particular attention. Test restricted content with users who have different permissions, and verify that retrieval excludes unauthorized material before it reaches the model. A cited answer still leaks information if the underlying passage was private. Controlled vocabularies also shape retrieval quality; see Intelligent taxonomy mapping for AI-powered Drupal systems.
Translation: separate draft generation from approval
AI Translate has a stable 1.4.2 release in this snapshot. Its 2.0 development branch is described as pre-alpha, so treat those branches as separate evaluation choices.
Translation can reduce repetitive drafting work, especially when your content already lives in well-defined fields. The budget, however, grows with source volume, the number of target languages, and how often you regenerate translations.
A useful workflow will track which source revision produced each draft. When the source changes, reviewers will then know which translations need attention rather than checking every language again.
Give reviewers the terminology they need. Product names, contractual wording, units, and regional phrasing need consistent handling, and language review remains part of the operating cost.
For teams already using a translation-management workflow, evaluate how AI-generated drafts will enter the existing approval process before introducing a parallel one. See Drupal multilingual websites: how AI cuts translation workload while your team stays in control.
Agents, context, and external access
Agents can move from suggesting an action to carrying it out. That changes the risk calculation.
AI Agents has a stable release, but production suitability depends on the tools and permissions available to each agent. Reading a published article is a different capability from changing site configuration.
Begin with narrow capabilities. Read-only access is easier to assess; write access needs clear limits, review points, and a way to recover from unwanted changes.
Tool API aims to make Drupal capabilities reusable across callers. MCP Server exposes capabilities to external clients using the Model Context Protocol. Both remain prerelease projects in this snapshot, and Tool API warns that APIs may change between betas.
Context Control Center addresses a related problem: keeping organizational context available to AI integrations. Its release-candidate status warrants evaluation, and the context itself needs an owner. Outdated product rules in a shared prompt can spread errors across several workflows.
The official Rotterdam recap from October 2 describes a usable integrated demo. It also explicitly labels the PHP-attribute-based capability-exposure approach a prototype. The Rosetta Sprint appears as a roadmap item.
Those distinctions matter. A working demo shows a direction; a prototype or roadmap item isn’t a released dependency you can plan around with the same confidence.
Package changes that affect upgrades
Older module lists can send teams toward deprecated package boundaries.
The AI 1.5.0 release notes explicitly deprecate the bundled AI Search and AI CKEditor components. AI Translate has been a separate project since AI 1.4.0.
For an existing installation, first inventory the submodules your site enables and the configuration that refers to them. Then check the documented migration route for the exact versions involved.
Don’t assume that adding a standalone package will migrate configuration automatically. The AI CKEditor replacement and migration path need confirmation before you schedule that upgrade.
For new work, select components from their current project pages rather than copying an older installation guide. That small check can prevent avoidable upgrade work later.
Provider configuration and cost control
Provider abstraction helps keep integrations organized. It doesn’t make every provider interchangeable.
Check the operations your workflow actually needs: text generation, embeddings, image input, tool calling, or structured responses. Verify support in the specific adapter and model combination, including any limits that affect your workload.
Then check where content will go. For confidential material, review the provider’s retention terms, processing locations, and contractual terms before sending it outside your environment. Keep credentials out of exported configuration and use separate credentials for development and production where supported.
Make token spend visible
Token spend often surprises teams because one user action can trigger several requests. An agent may take multiple steps; a review may run several criteria; a translation job may process many languages.
Long context adds up. So do retries.
Track usage by feature or workflow where possible, rather than relying only on a single provider invoice. A useful record links the request to its model, input and output usage, status, and originating job without retaining sensitive content unnecessarily.
AI Metering is an option for tracking usage, estimating costs, and applying quotas. Test its coverage in your stack. Its presence alone doesn’t prove that every request path has enforceable billing protection.
Use several controls together:
- Set input and output limits appropriate to each task.
- Put bounds on batch sizes, agent steps, and retries.
- Avoid regenerating unchanged content.
- Configure provider-side budgets or rate limits where available.
- Alert the team when usage deviates from expectations.
Self-hosting changes the cost structure rather than removing it. Compute, storage, monitoring, model maintenance, and operational support still need a budget.
What is ready for production evaluation?
There is no ecosystem-wide production-ready verdict. As of October 13, 2026, several components have stable releases, while others remain alpha, beta, or release candidates.
The stable-release shortlist includes the AI framework, AI Agents, AI Content Suggestions, AI Image Alt Text, AI Integration - ECA, AI Translate, AI Dashboard, and AI Metering.
AI Content Review, standalone AI Search, Context Control Center, Tool API, and MCP Server need a prerelease adoption decision. That decision may be reasonable for a bounded pilot, but it calls for explicit maintenance capacity and acceptance of change.
For a lower-risk first deployment, a human-reviewed editorial feature is often easier to contain than an agent with configuration-write access.
Before rollout, test the selected stack against a few practical questions:
| Check | What you want to learn |
|---|---|
| Dependency installation | Does the exact Composer combination install and pass your application tests? |
| Release maintenance | Does the selected release have the support and security-advisory coverage your organization needs? |
| Permissions | Can each user or agent read and change only the intended content? |
| Content handling | Do private fields, unpublished content, and sensitive data stay within approved boundaries? |
| Human review | Can reviewers inspect changes before publication and recover the previous version? |
| Failure behavior | What happens during timeouts, rate limits, invalid responses, and retries? |
| Operating cost | Can you measure a representative workload and stop runaway processing? |
These are implementation checks, not guarantees attached to a version number. Recheck releases and relevant issue queues before deployment.
Which components matter for this series?
For a series about Drupal in the LLM era, the most useful distinction is between making content usable by machines and using AI to work on that content.
Structured fields, taxonomies, stable URLs, language metadata, JSON-LD, and APIs form the publishing foundation. A site may need improvements there before it needs any model integration. That foundation also affects how assistants read your site, as we describe in Why Drupal sites get read and cited by AI and Beyond SEO: what we check in a Drupal AI-readability audit.
From that foundation:
- Editorial assistance and translation can help teams maintain structured, current content, with people reviewing the output.
- Automation can reduce repeated work across large content collections when triggers and retries have clear limits.
- Search and retrieval can help visitors or internal users find information expressed in different terms, provided retrieval respects access rules.
- Tool API and MCP integrations are relevant when external agents need controlled interaction with Drupal, with prerelease status factored into the plan.
You don’t need the entire stack. Choose one measurable task, test it with representative content, and inspect both the output and the bill before expanding.
Planning your next step? Bring Droptica a content workflow, search problem, or agent integration you’re considering. We can help you compare the relevant modules, identify dependency risks, and scope a pilot that will give your team useful evidence before a wider rollout. Learn more about our AI development for Drupal services.