How do you extend an existing Drupal site with AI agents?

The owner of a 3D printing workshop could no longer keep up with client requests. Printing took little of that time. Most of it went into retyping an address on the GLS portal, digging through WhatsApp for a measurement sent days earlier, and opening the slicer just to learn how long a print takes. That is the problem the owner brought to me.

I analysed the workshop's workflow, from the client's first message to the delivered parcel, and split it into twelve operations. I started with the ones that repeat on every order and picked a fitting technology for each: a deterministic agent (no AI), an AI agent, or a Mac app.

The owner is left with three operations: designing the part, starting the print and checking the result. That is the craft of the job.

At the center sits Drupal 11, the CMS the workshop already used with its clients, and it stays the only source of orders and statuses. Anything that reaches a client or the public goes out after the owner's yes.

What does Drupal do for a client?

Drupal runs an unusual kind of e-commerce here: it gathers requirements more than it sells from a catalog. The client describes what they need, and many parts are made to measure for them and stay private. On their page they follow the steps of the job: which parts are already printed, what is missing, the payment and the shipment tracking.

Drupal records the agreement: what the client asked for stays on file with their images, and every new request becomes a new line with its own price. Payment happens outside Drupal and the owner records it.

The data model carries everything else: a request is a node, each line is a paragraph, and the part is a node shared across several requests. Price, color, quantity and notes live on the line. As of 5 November 2026, Drupal held over 150 requests from more than 70 clients, about 700 order lines and almost 400 parts.

Where did the workshop's time go?

Every order went through twelve steps, and the owner covered all of them alone:

The slowest step was the first. To design a part you need measurements, photos and the client's answers, and an incomplete request stalls before the quote. Price and final agreements often slipped onto WhatsApp, away from Drupal.

What rule did I use to split the tasks?

For each operation I asked what it takes to do it well, and the answer chose the technology.

The rule puts AI where language is needed and a deterministic agent where the result must always be the same. The rest of the work is integration: connecting programs, machines and services that already existed.

Who does what now?

Below you can see how the workshop handled requests before and how it handles them now. The animation starts on its own: Replay shows it again, Speed slows it down.

The agents run on local models, on the workshop's server. Each agent has a role, a task and a written limit:

Next to the agents works a Mac app, written in Swift. It is a thin shell: it opens the Drupal pages in a window and adds only the links to the workshop's programs and machines. When Drupal changes, the app already shows the new version, with no reinstall.

• Part files: it connects to Fusion 360 and exports STL and STEP onto the part in Drupal, which becomes the single source of files.
• Times and settings: it passes the file to Bambu Studio or PrusaSlicer for slicing, the step where the printing software turns the 3D model into instructions for the machine. Drupal stores time and parameters by color, brand and material.
• Print batches: it takes the parts proposed by Sambuco, even from different orders with the same filament, arranges them on the plate in the slicer and sends them to the printer.
• Print status: it shows where each plate stands.
• Secretary panel: it shows the requirements gathered by Mora when the owner sits down to design.
• Shipping: it fills in the GLS and spedire.com broker pages with the order data, and the owner checks before confirming.
• Labels: it prints the parcel label on the label printer and the waybill on the regular printer, with the same command for every courier.
• Tracking: when the courier issues the code, the app fetches it and enters it in the order after the owner's confirmation, and the client receives it on WhatsApp and by email.
• Social: it assembles the reel for each channel and brings it to the owner for approval.

On the server, saving an STL generates the part video on its own, which social needs.

The owner keeps the Fusion 360 design, starting the print, quality inspection, the raw material for social and the approvals.

Which choices did I check against the facts?

Manual approval instead of a threshold. An automatic threshold looked like the most convenient solution, and I dropped it after measuring it: the classifier, the model that decides what type a message is, attaches a confidence score from 0 to 1 to every answer. That score sat almost always between 0.8 and 0.95 even when the answer was wrong, so it could not separate right answers from wrong ones. A proposal has an identifier, its full content, an author and an expiry. If the text changes, the approval lapses. There is a single exception: fixed-text shipping messages, approved once for all sends.

The production plan is deterministic. Sambuco sorts by delivery date, print status and time. A deterministic calculation can be checked with a test, and here that is what we need.

A deterministic agent routes, the model writes. Drupal uses its AI suite, which separates the CMS from the model. A gateway like LiteLLM would connect different providers, local or in the cloud, such as Anthropic, OpenAI and Google Gemini. I evaluated its Drupal module and left it out, because it is not covered by the drupal.org security advisories. The gateway is the workshop's server: Drupal talks only to it, and it dispatches requests to the models. There I change the model and the chat rules when needed, without touching Drupal. The price is some slowness, accepted in exchange for control. At first the model decided the routing, and the local models kept failing on the same cases. Now a classifier picks among closed options, a workflow routes and the model writes inside the assigned step.

WhatsApp through the official API. Every send by Mora has a count with its estimated cost, and the initial cap is 10 euros a month: once the cap is reached, Mora stops and alerts the owner.

Shipping through the interfaces already in use. GLS and the spedire.com broker offer paid APIs, or none, for a workshop of this size. The app fills in the same pages the owner used to fill in by hand, with addresses taken from the order, and the typo disappears.

A single source for files. STL and STEP live on the part. The 3MF produced by slicing belongs to the print, because it changes with color, brand, material and printer.

What happens when an agent gets it wrong?

A model makes mistakes, and the system is built so the mistake does not reach the client. Every message to a client or to the public is a proposal, and goes out only with the owner's yes. The model picks among closed options and writes inside the assigned step, and a deterministic agent checks the format of each of its answers.

When the owner corrects a proposal, the pair of wrong text and corrected text goes into the shared RAG memory. At the next similar request the agent finds that correction and uses it as an example. The model stays the same: what it remembers changes.

The cases where an agent got it wrong become fixed tests, rerun at every change of model or instructions. Every decision records model, request, answer and who approved it, so I can step in on a specific case.

Why does Drupal sit at the center of everything?

Drupal is the source of truth and the collector of the whole system. The workshop's Drupal already had a solid data model, so I did not rewrite it: I turned it into a platform, with a new dashboard for the owner, a PWA for phone and computer and a link to the local agent system. Approved facts live inside Drupal, work in progress lives outside:

1. Orders and statuses exist only in the Drupal database.
2. Agents and app go through Drupal's interfaces, which apply permissions and rules.
3. A cache speeds up a read, and when the two differ, Drupal wins.
4. If Drupal is unreachable, the agent says so and shows only what it knows for certain.

The local system runs on a workshop server: small Python services, models served by Ollama and a shared RAG memory, from which each agent reads client history, sheets and part files. Drupal sits on shared hosting, and the connection to the server is secured in several layers, with more than one check: every call carries a client certificate over mTLS, the proxy in front of the models lets through only two operations and at most 30 requests a minute, and address and certificates live in the environment settings, outside the exported configuration. Only one new field goes on the order line, the file number.

Dashboard, PWA and Mac app show the same Drupal pages. There is no separate mobile app and no second program to update: the owner changes a page in Drupal, and the new version shows up on phone, computer and Mac.

Where to start with an existing Drupal site?

Start from the workflow, before the technology. This is the order I would follow again:

1. Write down every step of the work, from first contact to delivery.
2. For each step ask what it takes: a calculation, language, a program or a machine, or the experience of the person doing the work.
3. Assign the technology with that answer.
4. Put an approval on every step that reaches a person.
5. Begin with the step where work gets stuck, using real examples.
6. Add the next step when the first one holds.

This is the first article in a five-part series. The next ones go into the detail of WhatsApp, the PWA and the infrastructure:

1. How do you extend an existing Drupal site with AI agents? (this article)
2. Requirements gathering with an agent on WhatsApp
3. The PWA and the coordinator as the single point of contact
4. The infrastructure behind Drupal
5. The numbers once the project is done

The method I used to write the code is in How I work with AI in development.

What does a Drupal site become when it works every day?

A site that tells who you are and what you do is the starting point. The value arrives when the same structure becomes the tool the owner opens every morning and takes the repetitive things off the owner's plate. With Drupal this was possible because the data model was already there: it only had to be connected to the rest.

This project took me beyond everyday PHP. The agents are in Python, the Mac app is in Swift, and the language became an implementation detail. What counts is the analytical mindset: reading a workflow, splitting it into steps and choosing the right technique for each. As a reference I used well-known paradigms, those of the sources below: deterministic workflows next to agents, RAG as a shared memory, human oversight over everything that reaches people.

Work like this changes some trades, and the change is coming anyway, today or in a few years. I prefer to accompany it. An infrastructure like this is a support for people who make their trade an art: the owner keeps the design, the printing and the eye on the finished part, and the agents sort out the rest.

Sources

• AI (Artificial Intelligence) (opens in a new tab), Drupal module
• AI Agents (opens in a new tab), Drupal module
• Building effective agents (opens in a new tab), Anthropic: deterministic workflows and agents, and when to use each
• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (opens in a new tab), Lewis et al., 2020: the paper that introduced RAG
• LLM06: Excessive Agency (opens in a new tab), OWASP Top 10 for LLM applications: why an agent does not decide on its own
• Article 14 of the AI Act, human oversight (opens in a new tab)
• Ollama (opens in a new tab), for local models
• LiteLLM, supported providers (opens in a new tab)
• Security advisory policy (opens in a new tab) of drupal.org
• WhatsApp Business Platform (opens in a new tab)