We will try to give back information about what is happening on the technical side, so people can stay up to date with improvements happening in the Drupal AI space from a developers perspective.
I was recently myself away on vacation for some weeks, and realized just how quickly everything is moving, both in the AI space and the Drupal AI space when you are not actively following it. The Drupal AI Initiative and its people contributing to it, outside of FreelyGive, have started its own momentum.
So this is a way to get a bi-weekly update on what is happening outside of releases, to be able to test things happening on the dev branches of different projects.
Tool API is released
The first alpha release of Tool API happened in the past week. The idea behind the Tool API is to create one uniformed API for any type of tool with clear input and output schemas. These will be able to be used both as function calling tools for AI, for tools for MCP, but also in the future derive actions for powerful automation tools like ECA.
In practice it means that you can define a tool once and use it in multiple systems, including as a function call for AI. The idea with this is that you should be able to create reusable tools for manipulating entities, using views as context, getting information about the Drupal system etc. simply in the GUI and be shipped as configuration.
This together with the functionality to create completely custom function calls in the UI using ECA, opens up for shipping a lot of agents as configuration without other module dependencies.
Tool API is being released as its own module, since the possibilities of how to use this is something that is outside of the scope of just the AI module.
Going forward with the MCP Client, we will most likely use Tool API as well as the foundation to make sure that any tool from a MCP server you want to create a version of inside Drupal.
A huge thanks to Michael Lander who has been working tirelessly on this project and for all the expertise he has been giving back to the AI project in general.
A video of the tool api in action creating Drupal content that with Claude Desktop and MCP using natural language can be found here.
Image-To-Image operation type is merged
One year ago when the initial Image to image operation type was thought of, it was a fairly “useless” AI inference type. The problem was that the AI models could not keep consistency, meaning that at best you could use it for some nice demoing purposes, most of which made little sense to use in a Drupal context.
This has somewhat since changed, with Dreamstudio offering things like removing backgrounds, outpainting of images to fit specific ratios etc. and OpenAI GPT-1-Image making it possible to generate images in a style of another image. This was what it was initially meant for.
However, since the issue was put “in review” and it has now been merged, Nano Banana was released and is a complete game changer in this field. It lets you edit images in natural language with very good consistency and gives a future image of what is to come.
We just need to add that to a provider now and we will have a way for a chatbot or another prompting interface to change images directly inside Drupal using natural language.
Use Tavily in your agents to do web searches and research
The Tavily module got another release - 2.0.0-rc3. Tavily is a service specifically designed for connecting your agent to the web.
The main feature of this release is a function call that you can use in your agent to do web searches to get either full html scraped webpages or markdown versions of the websites it finds.
This means that you can have an agent summarizing some topic for you or fact checking something for you.
See more here: https://www.drupal.org/project/tavily
Support for Fibers
Currently the AI module is treating any provider synchronously. This means that if you ask for instance OpenAI four different things that are not dependent on each other, we at the moment run the first one, start the second one when the first one is done and so on.
This change makes sure that we can utilize Fibers in PHP and run this asynchronously, so the process only becomes as slow as the slowest of the four calls in this case.
Currently we have no real case usage of this, but future jobs like for instance AI Translate, where each field translation is independent of the other, could work in parallel to translate a lot faster.
See: https://www.drupal.org/project/ai/issues/3538027
Removing code reiteration and reusing provider standards
A lot of providers today are using a standard that OpenAI created for its messaging API platforms. This means that a lot of providers can actually reuse a lot of code that we initially set up for the OpenAI provider.
The problem is that you do not want to make a provider dependent on the OpenAI provider, just because you want to inherit functionality from it.
Because of this we have opted to create a base class for OpenAI based providers, outside of the normal base class.
You can see the base class here.
We have already started removing huge chunks of code that was just duplication of code found in other providers.
Other smaller but noticeable fixes:
-
The AI Translate’s Drush command to translate can now take multiple ids, instead of just one: https://www.drupal.org/project/ai/issues/3537084
-
We have added a marker interface for all exceptions the AI module throws, so you can catch em’ all: https://www.drupal.org/project/ai/issues/3542498
-
The StreamIteratorInterface has been worked over for 1.2.x release, without being backwards breaking, but with provider developers needing to take a step to make logging of the response working. This is to prepare for making tool calling possible using streamed output:
Stay tuned for further bi-weekly Drupal AI development progress. Visit the Drupal AI Initiative home for ways to connect and get involved.