Choose a Drupal AI chatbot by deciding who will use it and what that person must accomplish. An administrator asking an assistant to create a content type needs a different system from an anonymous visitor asking about an application deadline. A similar chat window does not establish the same sources, permissions or actions. Start with a task-to-audience requirements card, then evaluate the documented capability that matches it.
Author: Achla AI, Organization. Reviewed 14 October 2026. Prepared with AI assistance using official Drupal documentation and Achla product sources. The tables are original decision tools; the examples are hypothetical. No customer results, completed browser tests or product ranking is claimed.
Choose the actor before choosing a Drupal AI chatbot
“Drupal AI chatbot” can describe an assistant working inside administration, a configurable chat block, or a public website-answer service. The useful distinction is the actor's goal. Is someone trying to change Drupal, find published information, inspect their own account, or reach a person?
Write one sentence: “A [visitor/editor/member] needs to [specific task] using [permitted information].” If the sentence includes two audiences, split it into two requirements. An editor's permission to configure the site does not explain what an anonymous visitor should be able to ask.
Keep the initial decision small. You do not need to choose a vector database to establish that “create a field” and “find the cancellation policy” are different jobs. The separate Drupal RAG architecture guide covers implementation ownership after that boundary is clear.
What belongs to an administrative assistant?
Drupal's official introduction to AI in Drupal CMS 2.0 describes an admin chatbot for site-building tasks, including creating content types, defining taxonomy terms and adding fields. Those are configuration tasks performed for a site builder, rather than evidence that the same interface answers public visitors' questions. Drupal CMS AI overview.
For an administrative requirement, name the intended change. “Help with content” is too broad. “Suggest the fields for a course content type” and “create those fields in Drupal” have different acceptance conditions. A suggestion can be inspected before anyone acts. An actual configuration change needs the site's normal permission, review and recovery decisions.
A useful requirements card therefore separates proposal from execution. Record whether the assistant should merely explain a task, prepare an editable proposal, or perform a permitted change. Then ask the tool's documentation to support that exact behavior. Do not infer write authority from a screenshot of a conversation.
Also identify who owns the resulting configuration. A marketing editor may request a new content type, while a maintainer approves its field definitions and deployment. That ownership is a site decision; the article is not asserting that a particular module supplies an approval workflow for every requested action.
If your requirement ends with changed taxonomy, fields or configuration, evaluate an administrative tool first. A public-information widget is not an alternative just because it also uses AI.
What belongs to a visitor-answer assistant?
A visitor-answer assistant helps someone use information the organization has chosen to publish: an eligibility rule, a service description, a product manual or a policy. A useful response should lead the visitor to supporting material and a meaningful next step.
Drupal project pages illustrate different ways to approach this job. AI Content Chat describes selecting content types and text fields for indexing and placing a visitor-facing block. Custom AI Chatbot describes a frontend block with a configurable prompt and custom context. These are documented designs, not proof of equivalent accuracy, operating behavior or fit for every site. AI Content Chat, Custom AI Chatbot.
The boundary changes when a visitor asks, “Has my application been approved?” Public guidance can explain the application process. It cannot establish the person's actual record. Likewise, explaining a booking policy does not make a booking, and describing contact options does not connect a live agent.
Keep these differences visible during procurement. Ask separately about public sources, authenticated information, actions and human service. A product may support one category without supporting the others.
For Achla, the evidenced use case is a managed website-content answer widget with source links. Its Drupal product page is the relevant starting point for that public-information job. This guide does not claim private Drupal retrieval, account lookup, lead collection or staffed human chat.
Use the task-to-audience decision matrix
The following examples are hypothetical requirements, not tested module capabilities. Use the table to choose the class of system you need before comparing products.
| Desired task | Actor and permitted source | Required behavior | Product class to investigate | Stop or evidence question |
|---|---|---|---|---|
| Add a field to a course content type | Authorized site builder; Drupal configuration | Propose or perform a configuration change | Administrative AI assistant | Does documentation support the exact action, and who approves it? |
| Find an application deadline | Anonymous visitor; approved public page | Explain the published date and link to it | Public-content answer assistant | Is the relevant deadline publicly available and current? |
| Check my application status | Authenticated applicant; personal record | Retrieve the correct person's status | Verified account-aware service | What enforces identity and record access? Public pages are insufficient. |
| Collect a prospect's email | Visitor; information intentionally submitted | Capture and route personal contact data | Verified form or lead-capture system | Where is it stored, who receives it, and is capture actually supported? |
| Change a booking | Customer; booking record and permission | Execute an authorized transaction | Verified transactional workflow | Can it perform this change safely, rather than explain the policy? |
| Speak to a human now | Visitor; request for conversation | Reach a staffed person or state availability | Live-chat service with operational staffing | Is transfer native, or does the interface only show a contact link? |
The table is intentionally not a ladder from “basic” to “advanced.” A small site with clear public policies may need only the second row. A member portal may need account access from the beginning. Neither requirement can be resolved by counting the number of providers listed on a module page.
Mark each row required, optional or out of scope. A required capability without evidence is a purchasing question, not a feature to assume. Avoid combining the rows into a vague demand for “an AI agent that does everything.”
Read module pages as evidence, not as feature equivalence
A chat block identifies an interface, not a complete source or action contract. The Drupal AI Chatbot documentation describes a block that processes messages through ChatProcessor plugins; it requires the AI module and a configured provider. The selected processor matters to what happens behind the input box. Drupal AI Chatbot documentation.
Use a dated evidence register rather than a universal “best chatbot” list:
| Documentation inspected | Documented evidence | What still needs a buyer's answer |
|---|---|---|
| Drupal CMS AI overview | Admin assistance for named site-building tasks | Which requested operation is supported on your installation? |
| Drupal AI Chatbot | Block interface, provider requirement and processor selection | Which processor supplies your intended source and behavior? |
| AI Content Chat | Visitor questions from selected indexed content | Does the selected collection and actual configuration meet your approved scope? |
| Custom AI Chatbot | Frontend block with configured prompt and custom context | How will your source material be supplied and maintained? |
| GPT-Based Chatbot Integration | Visitor interaction and provider-key setup described | Which documented behavior matches your requirement rather than a broad AI label? |
The final row refers to the GPT-Based Chatbot project. This is a documentation comparison, not a deployment recommendation or a measured performance comparison.
As reviewed on 14 October 2026, the AI Content Chat, Custom AI Chatbot and GPT-Based Chatbot project pages state that they are not covered by Drupal's security advisory policy. Record that label as a dated maintenance consideration. It does not establish that any project is unsafe; nor does a directory listing establish that it has passed your site's review. Check the current project page again when selecting a release.
Compatibility also needs separate evidence. A module's stated PHP minimum does not settle the requirements of the Drupal core version you run. Ask the maintainer to check the whole installation against current requirements rather than interpreting a package floor as universal compatibility.
Write a requirements card before starting a pilot
Here is a hypothetical card for a public training provider's Drupal site. It has not been run on Achla or any other product.
| Field | Illustrative completed requirement |
|---|---|
| Actor | Anonymous prospective student |
| Task | Find the published prerequisite for a particular course |
| Permitted source | Public course page and approved admissions policy |
| Desired outcome | Short explanation with links to those documents |
| Read or write | Read and explain only; no application or account change |
| Human requirement | An independently visible admissions contact for exceptions |
| Required product evidence | Documented public-content answers and inspectable source links |
| Explicit non-goals | Collect personal application data, decide eligibility, promise admission |
| Unknown to resolve | Does the real course page contain the prerequisite unambiguously? |
| Owner decision | Admissions owner approves the wording; maintainer owns installation checks |
The card prevents a common buying mistake: treating every conversation as permission to act. Finding a stated prerequisite and deciding whether an individual qualifies are different commitments. Keep the assistant's job on the first side unless another verified workflow supports the second.
Use a second card if the same organization also wants help creating course fields. That card has a site builder as actor, configuration as source and a proposed or permitted write action as outcome. It should not borrow the public visitor card's approval.
Bring these cards to an evaluation. Ask the supplier to show the relevant documented feature and identify every unknown. Keep undocumented capabilities marked unknown, even when a demonstration appears persuasive. If you need a broader category comparison, the existing AI site-search overview can inform your shortlist; it cannot replace this requirement-specific evidence.
Which requirements stop a public-content widget evaluation?
Pause this product path if an essential task requires private member information, administrator changes, bookings, lead capture or a staffed live conversation and you have no verified capability for it. The right response is to investigate a suitable product or separate service, not make private content public to simplify a crawl.
A contact link can remain useful, but it is not evidence of native human handoff. A source link can help a visitor inspect a policy, but it is not permission to modify a record. A provider connection can generate text, but it does not prove the complete visitor workflow.
Keep the stop list beside the requirements card. If a capability is optional, record how the site already handles it. If it is required, resolve it before selecting the product. This keeps a bounded public-answer evaluation from quietly becoming an account-service project.
Where a managed Drupal answer widget fits
Achla is a candidate when the approved job is helping visitors find and understand public website information with supporting source links. Review the current installation instructions for its Drupal connector and documented placement choices. Use troubleshooting guidance for installation checks, and the current pricing page for commercial terms.
If that boundary matches your requirements card, begin onboarding; sign-in may be required. Bring one public visitor question and its supporting page to decide whether the documented public-answer path fits the task.
