How to Add AI to Moodle: The Three Paths

"How do I add AI to Moodle?" is really three questions wearing one coat. A site administrator asking it usually means which provider key do I configure, and who is allowed to spend it. A teacher asking it means can something write my quiz questions and mark the short answers. A head of department asking it means what do I have to buy, and what will the DPO say.

There are three real routes, they answer those questions differently, and none of them is a strictly better version of another. This piece walks through all three — what each one genuinely does today, what it will not do no matter how you configure it, and the case for choosing it.

The short version

• Moodle's core AI subsystem — built into Moodle since 4.5. Your administrator configures an AI provider and switches on placements; users get generate, summarise and explain actions in the editor and around course content. It does not mark student work and it does not build question banks.
• A plugin installed in your Moodle — code running on your server, from the Moodle Marketplace. Enormous range, from tiny helpers to full AI features, and the quality and the maintenance burden are yours to assess one plugin at a time.
• An LTI 1.3 tool — an external application registered once under External tool, which then behaves like a native activity in every course. This is where classroom workflows live: question generation, rubric-based marking with grade passback, a tutor scoped to your lessons.

First, decide what you mean by "AI"

Almost every bad Moodle AI decision starts by skipping this step. Write down which of these you actually need, in order, before you evaluate anything:

1. Authoring help — rewrite this announcement, summarise this forum thread, draft a paragraph, make an image for the header.
2. Content generation — turn this syllabus into lessons, slides, a study guide, a worksheet.
3. Assessment generation — produce a question bank from a chapter, with difficulty control and an export my LMS will accept.
4. Marking — read a submission, apply a rubric, propose a score, and put it in the gradebook.
5. Learner support — a tutor that answers from the course material and does not hand out the answer to a graded item.

Path 1 covers the first item well and stops. Path 2 covers whichever items its author chose to build. Path 3 is where items 2 to 5 generally live. If the only thing you need is the first item, the rest of this article is optional reading and you can be finished in an afternoon.

Path 1: Moodle's core AI subsystem

Moodle 4.5 introduced a proper AI subsystem in core, and it has been developed in every release since. It is genuinely well designed, and if you run Moodle you should know what it does before you buy anything.

The architecture has three moving parts. A site administrator configures one or more providers — the connection to an AI service. Then they enable placements, which are the surfaces where AI can appear. Each placement exposes specific actions, and the administrator chooses which actions are available in each. Everything is off until somebody deliberately turns it on.

Providers, and whose bill it is

The core provider list has grown with every release. OpenAI and Azure AI shipped with the subsystem in 4.5. Moodle 5.0 added Ollama, for models you host yourself — which matters a great deal if your institution will not send student text to a hosted API. Moodle 5.1 added DeepSeek, and 5.2 added Gemini and Amazon Bedrock. In every case the institution supplies its own API key and pays its own provider bill. There is no included allowance and no Moodle-operated AI service: Moodle gives you the plumbing, you bring the water.

Placements and actions

The two core placements are the text editor and course assistance. The editor placement puts an AI control inside the editor, where the generate-text and generate-image actions live. The course assistance placement puts summarise and explain controls onto course content — pages, quizzes, discussions — so a learner can ask for a plainer version of something dense.

So the complete action list is four items: generate text, generate image, summarise text, explain text — the last of these added in Moodle 5.0. Each has its own capability, so you can let staff generate text in the editor while leaving image generation off, or give learners the summarise control without the generate one. Moodle 5.1 added a much friendlier layer on top: AI access controls at the course and activity level, rather than everything living in site-wide permissions pages.

The governance around it is better than most people expect. The first time any user tries to use AI through any placement, they are shown an AI usage policy they have to accept before proceeding. Moodle 5.0 added two site reports to go with it: an AI usage report showing how and when each enabled provider has been used, with tokens, context and users; and an AI policy acceptance report listing who accepted and when. Both are manager-only.

That restraint is a choice, not an oversight. Marking is the part of an LMS where an error is expensive and contested, and Moodle HQ has been conservative about shipping it in core. The practical consequence: if someone tells you "Moodle marks essays with AI now", they are describing a plugin or an external tool.

Choose this path if…

• You mainly want editor-level assistance — rewriting, summarising, the occasional image — and nothing that touches grades.
• You already have an institutional OpenAI, Azure or self-hosted model account, and you want every call to run through that one key rather than a dozen personal accounts.
• Nothing may leave your infrastructure. With an Ollama provider pointed at a model you host, the AI call never reaches a third party at all. No LTI tool can match that.
• Your governance requires site-level control over exactly which roles may invoke a model, with the whole thing off by default.

And do not choose it as your only path if you need marking, question banks, or a subject tutor — it will not grow into those, because it is not trying to.

Path 2: a plugin installed in your Moodle

The plugins route is the oldest and broadest, and the AI category has grown quickly: question-type plugins, AI provider plugins that extend the core subsystem to another model, chatbot blocks, marking helpers, registration helpers. Some are maintained by full-time teams; some are one person's good idea from two Moodle versions ago.

One piece of housekeeping first, because it changed recently and a lot of bookmarks are now stale: the old Moodle plugins directory went read-only in July 2026 and has been replaced by Moodle Marketplace, at marketplace.moodle.com, which is where new submissions and browsing now happen. The AI category there carries subcategories for AI providers and AI placements — the two plugin types the core subsystem defines.

The defining characteristic is that a plugin is code running inside your Moodle. That is the source of both its advantages and its costs.

There is also a hosting constraint worth establishing before you spend an afternoon shortlisting: installing plugins requires a Moodle you are allowed to install plugins on. Self-hosted Moodle is fine — a plugin can be deployed from inside Moodle, from the directory or as a ZIP upload, provided the web server process can write to the plugin folder; otherwise it is a manual copy onto the file system. On Moodle's own hosted MoodleCloud service, the support documentation is unambiguous that site administrators cannot install their own plugins, so on that platform this whole path is closed and your choice is between paths 1 and 3.

A common source of confusion belongs here too. Moodle's long-standing Essay (auto-grade) question type is frequently described as AI marking. It is not: it awards a provisional grade from the number of words, sentences and target phrases in the answer, and the teacher can override it. It is a rule-based heuristic — completely predictable, and completely blind to whether the argument is any good.

Choose this path if…

• You have an active Moodle IT team that already installs and upgrades plugins as routine work, not as a project.
• You need something genuinely inside Moodle's internals — a new question type, a change to how an existing activity behaves.
• You want to extend the core AI subsystem to a provider it does not ship with, which is exactly what the community provider plugins exist for.
• You are comfortable evaluating a plugin the way you would any dependency: who maintains it, when was it last released, which Moodle versions does it claim, and what does it call out to.

Path 3: an LTI 1.3 tool

The third route is not a Moodle component at all. LTI 1.3 — Learning Tools Interoperability, a 1EdTech standard — lets an external application plug into any compliant LMS and behave like a native activity. Your administrator registers the tool once under Site administration → Plugins → External tool → Manage tools, and it becomes available in every course. Teachers then add it from the activity chooser like a Quiz or an Assignment; learners open it with their existing Moodle identity and never see a second login.

The version number matters. LTI 1.3, often branded LTI Advantage, adds the three services that make AI tooling actually useful:

• Deep Linking — the tool can hand a specific item back into the Moodle course, so an activity is a real link rather than a copied blob.
• Names and Role Provisioning (NRPS) — the tool knows who the learner is and what role they hold, without you managing a second user list.
• Assignment and Grade Services (AGS) — grades from the external tool land in the Moodle gradebook automatically. For anything involving marking, this is the whole ballgame.

Registration, and the three-minute claim

Modern LTI tools support dynamic registration, which Moodle has implemented natively since 3.10: the administrator pastes the tool's registration URL into Manage tools, clicks Add LTI Advantage, reviews the tool card and the services it is asking for, and clicks Activate. No copying client IDs, no exchanging keys by email. That is the honest basis for the "about three minutes" figure you see quoted — including ours. It covers the administrator's three steps; adding the activity to a course afterwards is a teacher's job and takes another minute.

Dynamic registration does assume one thing, and it is the assumption that trips up more institutions than any other: completing it involves a server-to-server exchange, so your Moodle has to be reachable from the tool's side. Plenty of real Moodles are not — behind a firewall, on an intranet hostname, behind a WAF or bot protection, or on a private network entirely. For those sites the standard registration flow simply fails, usually with an error that does not explain why.

This is where EduGears AI does something specific, and it is worth describing exactly rather than in slogan form. There is an optional Moodle plugin, local_edugears, whose only job is registration. Install it, and clicking Register EduGears AI on its settings page creates the external tool locally inside your Moodle and posts the registration from the administrator's browser — so you skip the Manage tools navigation and the tool-configuration step entirely. If your Moodle is publicly resolvable, that is genuinely one click.

For a Moodle our servers cannot reach at all, there is a second step and you should know about it before you start: a manual registration page takes the registration code from the plugin and your site's public JWKS key file, pasted in by the administrator, and completes the connection from those two values. The combination is what means a private Moodle never needs a public URL — not the plugin alone. The keys file is public by design and contains public keys only; publishing it is how LTI 1.3 lets a tool verify that a launch really came from your site.

And if your Moodle is reachable from the internet, you do not need the plugin at all — the plain registration URL works, and it is the same URL used for Blackboard and Brightspace.

What you get, and what it costs you

Because an LTI tool runs on the vendor's infrastructure, it can carry workflows that would be unreasonable to install on your server. In EduGears AI's case that is 26 tools inside one registration — question generation across nine question types with QTI export, quizzes with grade passback, rubric-based marking, capstone and project work, a lesson planner, slides, study guides, worksheets, course import from SCORM, Common Cartridge and Moodle backups, and Cog, one assistant reachable from every page that already knows the lesson you have open.

The differentiator that has nothing to do with features is portability. Because the integration is the standard rather than a Moodle-specific add-on, the same tools behave the same way in Canvas, Blackboard and Brightspace. If your institution runs more than one LMS — which is more common than anyone admits, usually a Moodle in one faculty and a Canvas in another — that is the difference between one rollout and three.

The cost is the obvious one: student text and generated content pass through a third party's servers. That is a real trade against path 1's Ollama option, and it is answered with contracts and configuration rather than reassurance — a data processing addendum, a retention window you set, and bring-your-own-key so the model calls run against your institution's own provider account.

Choose this path if…

• You need classroom workflows — question banks, rubric-based marking with grade passback, a tutor grounded in your lessons — rather than editor assistance.
• You want teachers to have it this week, without a server change, a maintenance window, or a plugin to re-test at the next Moodle upgrade.
• Your Moodle is on a hosting tier that will not let you install plugins at all.
• You run more than one LMS, or expect to migrate, and you would rather not repeat the exercise.
• You are willing to do the vendor diligence — DPA, retention, training policy — that any external processor of student work deserves.

The three paths side by side

Most sites end up running two of them

The framing of "which one" is slightly false, because the paths do not conflict. The common shape in institutions that have been at this for a year looks like this: the core AI subsystem switched on for editor assistance with an institutional provider key, and one LTI tool registered for the assessment and content workflows. A plugin or two in the mix where something specific was needed.

That combination is cheap to run because the pieces do genuinely different jobs. The core subsystem never competes with the LTI tool for a workflow, and the LTI tool never asks your IT team for a maintenance window. The one thing worth being deliberate about is telling staff which is which, because two AI buttons in one Moodle with no explanation produces support tickets rather than adoption.

A checklist before you commit

1. Write the five-item list from the top of this piece in priority order. If marking is not on it, you may not need paths 2 or 3 at all.
2. Check what your hosting allows. Can you install plugins? If not, path 2 is closed and the decision is simpler than you feared.
3. Check whether your Moodle is reachable from the internet. This determines whether LTI dynamic registration will complete on its own, and it is a five-minute question your infrastructure team can answer.
4. Decide where student text may go before you evaluate vendors, not after. Self-hosted model, hosted provider under contract, or bring-your-own-key — pick the line and hold it.
5. For anything that marks, find the approval step. Ask whose rubric is applied and whether a human sees the score before the learner does. If the answer is vague, that is the answer.
6. Pilot in one course, with one teacher who will tell you the truth. A term of real use beats any comparison table, including this one.

Frequently asked questions

Related reading: Moodle's built-in AI vs an LTI AI tool goes deeper on the choice between paths 1 and 3, and can Moodle grade essays with AI covers the marking question on its own.