Ahead of DrupalCamp Tokyo 2026, James Abrahams Outlines Priorities for Drupal AI

Before his DrupalCamp Tokyo 2026 keynote, James Abrahams answered written questions from The DropTimes’ Allen Jason through the event organisers. James, co-founder of FreelyGive, co-founder of the Drupal AI Initiative and one of its innovation managers, discussed cost controls, agent workflows, Drupal CMS alignment, Symfony AI and multilingual readiness. His answers connect the camp’s AI focus with practical questions facing Drupal site owners, maintainers and multilingual teams.

The interview matters because James is helping shape Drupal AI at the initiative level while leading FreelyGive, a UK-based company providing Drupal and Customer Relationship Management solutions. His responses frame Drupal AI’s next phase less as a set of isolated features and more as an operational question for teams using AI in production. For site owners and maintainers, the challenge is how Drupal can control provider use, keep agents aligned with Drupal patterns and support multilingual markets where context and evaluation are harder to generalise. The following written exchange has been lightly edited for clarity.

TDT [1]: As Drupal AI workflows become more capable, token usage and provider costs become part of site architecture. How is the initiative approaching cost governance at the Drupal level? Are there plans for built-in throttling, role-based limits, provider caps, observability, or budgeting tools?

James Abrahams: Absolutely, we designed our system to be highly pluggable, so there are already a number of third-party modules that integrate with the AI module to handle throttling and role-based limits, etc.

One thing we’ve found recently is a move towards a greater focus on what is called “Out-Side in” AI. Drupal exposes its tools and APIs to AI harnesses such as Claude Code, which then handle the connection to the AI APIs. This means these external systems can somewhat handle some of the above.

We’re very driven by use-cases, though, and so people wanting more of these features should reach out in #ai-contrib to ask questions about it.

TDT [2]: Drupal AI 2.0 appears to involve a clearer architectural separation between AI Core, official modules, recipes, providers, dependencies, and contrib space. What should existing users and maintainers expect from that transition, and how are you trying to avoid disruption or maintainer fatigue?

James Abrahams: Our focus is on Drupal CMS or perhaps an AI-focused site template for Drupal CMS. We’re aiming to create something, as we did with the Drupal AI Assistant Recipe, that feels more like an off-the-shelf product that solves problems for you. The AI Initiative as a whole looks across the whole ecosystem of modules that are kind of “Drupal CMS” approved, and that helps existing users transition to the new officially supported ways of handling things.

Ultimately, there is debate on things such as “Maintainer fatigue” and backwards compatibility, etc. Many AI maintainers really want to be as helpful as possible, reduce fatigue for themselves and the users of the AI module and make things seamless.

Personally… I take the approach that we are all fighting for our lives amid the disruption AI causes, and that moving forward aggressively to capture the benefits AI brings is the primary goal, so we can produce value and make money. Many of these problems become much easier to solve when more money flows into the ecosystem, as more end-user value is generated.

You May Like

Article

Drupal Association Opens Self-Nominations for 2026 At-Large Board Election

Article

Drupal Association Opens Self-Nominations for 2026 At-Large Board Election

I am also big on trying, as much as possible, to make it so that one company or person doesn’t have to own everything, and that we work together and use interoperable tooling.

One major shift in Drupal AI 2.0 is the move towards Symfony AI. We’ve been following their initiative closely since it was first announced, and we have shared a lot of knowledge, so this has been a great fit. It helps us share the burden of low-level AI code or management of model metadata, so that it is no longer something only Drupal has to manage and becomes part of the PHP community.

TDT [3]: With AI agents and no-code workflows becoming more central to Drupal site building, where does human architectural judgment still become non-negotiable? Is there a point where the site builder has to stop prompting and start thinking like an information architect?

James Abrahams: It's very hard to predict this one, and so we’re working on all approaches to see what sticks. In the case of AI Agents working from the outside in, we’ve started working on a project called “AI Best Practises”. It comes with a helpful installer to get you started working with Drupal and harnesses such as Claude Code. This comes with a collection of skills and tooling for “Evals”, so we can direct AI to build things or architect things in a certain way.

This is kind of like human architectural judgement, but it's the whole community working on those best practises together and testing if AI does things correctly. The hope is that these skills can do much of the work of an “Information Architect” and guide people to the right places.

We’re really working on trying to get AI to make use of existing modules instead of creating its own stuff, which is the biggest issue with AI right now.

TDT [4]: AI-assisted design and site-building tools can sometimes converge toward safe, familiar patterns. How is Drupal AI thinking about originality, variation, and editorial control so that generated layouts, content models, or workflows do not all start to look the same?

James Abrahams: I think our focus is less on that and more on getting things into Drupal from any source. If we can get AI to get really good at analysing a design, an existing site, etc., and then figure out the correct architecture for building that design in Drupal while benefiting from a good user experience for editors, all while still working within the Drupal ecosystem of modules. The wider AI community can figure out how to solve that problem. There is so much work going into things like Claude Design or Figma AI, that we don’t need to fundamentally solve that. We just need to make it so that, whatever design or approach you decide to take, Drupal can hold it, scale it, and make it work in the real world fast.

TDT [5]: Drupal has long multilingual strengths. As AI agents begin working across content, layout, translation, and site-building workflows, what are the current challenges in handling high-context languages such as Japanese? Are context, nuance, tokenization, and evaluation being addressed in the architecture?

James Abrahams: This is a major issue that we are looking into and hoping to resolve, but we just haven’t seen a great deal yet, as we’ve been somewhat waiting on Canvas’ support for multilingual. For many of us, Multilingual support was what brought us to Drupal in the first place. To a degree, the canvas support of multilingual is where Canvas will really be production-ready for us in Europe and outside the US. Even in the US, it's been a major request!

It should be out this month or next, and then we can get into the weeds with a language such as Japanese. It’s very much something we’d love support for!

(It does help that Marcus is half Japanese and the tech lead for the AI module!)

James is scheduled to deliver the keynote session, “Drupal - The best CMS for your agents to use!”, in Track A at DrupalCamp Tokyo 2026 from 10:20 to 11:20 JST on 27 June 2026. The session will cover Drupal’s structured architecture, the AI module, the Drupal AI Initiative and AI Best Practices as part of a broader look at how AI agents can work inside and outside Drupal. Visit the official website: https://www.drupal.jp/tokyo2026