Is it integrated with ECA?

Hi, its not. You are not the first to request this, so I will look into it :)

Connected that issue where ECA was talked about within Interpolator.

@Marcus This https://www.drupal.org/project/prompt → may be a simple example where ECA is implemented. Like in this picture: https://www.drupal.org/files/project-images/Fox2QoOXsAIEQWt.jpeg →

Here is where @AlfTheCat listed many various use-cases for ECA: #3350297-4: Creating chatGPT ECA action →

This is practical example where Augmentor puts ECA to very good use: #3377394-5: Content moderation AI copilot →

I don't have good idea how ECA relates to Intepolator, or if it should be implemented, since Augmentor already do this (?)

I have looked into the ECA module since I didn't work with it before. Since the AI Interpolator module already have a plugin system built for different processors it would be easy enough to add an ECA processor.

This could be an external module, similar to the Post OB Processor → module for more advanced use cases like conditions or child entities. So anyone using the base use case can just use it as of today.

I can think of two ways that this could work.

Controlled via AI Interpolator
This is the less preferred solution for me, but it doesn't create any UX nightmares on already installed Interpolators. In this case you would setup the Interpolator as today, you just choose "ECA" as the processor.

Then in ECA there would be an AI Interpolator Action for presave that you can put anywhere you want.

Controlled via ECA
This makes all the rules available via ECA forms as well. This would require some rewrites and I would either have to figure out how to know the base entity that is connected to action, so you can choose which field to find rules on, or make all rules available (bad UX).

The processor has rights to overwrite the main field configuration form checkbox in this case. The most work/biggest problem is to have some kind of migration module between AI Interpolator mode and ECA for anyone that started with one mode and want to migrate to the other without having to rewrite anything But I guess that is a follow up feature.

Anyone with some feedback on the two solutions (or a third)?

@fishfree - There is a first version of a processor module now. Check out https://www.drupal.org/project/ai_interpolator_eca →

I will set it to "Needs review" and if anyone that uses ECA could test it, that would be nice. Thanks.

@Marcus Thank you for your diligent work! I will try it!

Hi @marcus, really excited to see the new module!

I just tried to install it via composer which produces an error:

sudo -u www-data composer require 'drupal/ai_interpolator_eca:^1.0@alpha'
./composer.json has been updated
Running composer update drupal/ai_interpolator_eca
Gathering patches for root package.
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Root composer.json requires drupal/ai_interpolator_eca ^1.0@alpha -> satisfiable by drupal/ai_interpolator_eca[1.0.0-alpha1].
    - drupal/ai_interpolator_eca 1.0.0-alpha1 requires drupal/eca_content-eca_content * -> could not be found in any version, there may be a typo in the package name.

I went rogue and installed it manually which worked :)

I missed Marcus' comment #5 at the time, and based on my experience in the past months I can offer a slightly different perspective on the question of field-level interpolation vs making interpolation rules available to ECA. I think both methods can exist side by side. For some smaller/ less complex AI implementations, field-level interpolation is easier and faster for users without ECA experience to set up and use. Field-level use cases would be where there are single content editors that perform AI content operations and the operations are mostly limited to the data contained in single nodes. Here, content editors know why the form submits take so long, or are OK with looking at the interpolator batch process for a bit each day, or understand that it's normal that nothing happened and they need to check back in a while as cron processes the interpolator rules they just triggered.

Where it gets more complicated is when AI rules are triggered via community-based user submissions (comment moderation) or where AI rules are triggered conditionally, are chained over many steps, using data from various sources, pulling in data from other entities, need to be distributed over multiple queues, etc.

If it's just me and I'm running a blog with AI, using field-level rules is fine. But if I'm running a forum with lots of users and AI needs to moderate content and spice up the registration process as well as produce rich content with multiple images, then ECA becomes essential in managing, scheduling, evaluating, queueing, bulk processing, and more AI actions because the rate limits and the long execution times inherent to the process poses difficult bottlenecks and UX problems. The only way I can implement AI in any form I need and at scale is with ECA. I think people are not fully aware of what the ECA + AI combo brings to the game, and how it transforms Drupal into an AI powerhouse.

At the moment AI interpolator offers features not paralleled by other modules and I already couldn't do without it. The Openai module recently added ECA integration but lacks the support for images, lists, and more that AI Interpolator offers. Right now I use openai_eca in tandem with field-level AI interpolator but it is not ideal, and it would be perfect to just have the AI interpolator rules available in ECA, with multiple token support as Jurgen describes here ✨ Allow multiple tokens for replacement in ECA plugin Needs review . I don't think there needs to be an upgrade path or anything from the current implementation, users can do either/or but also both (maybe 99% of their rules don't require conditionality or other complexity, except that one special use case).

My two cents :)

@AlfTheCat - Thank you for the feedback, that is super valuable.

Basically having the field-level interpolation is kind of a must for our company and that's why it was built that way - we have editors that needs to be able to setup complex chains themselves, and while ECA initially gives a way better overview of what is happening at first glance, it's also a way higher learning curve.

The other advantage I think that was clear to me from the start is that if you know how the complex field type that you are interpolating from and to you can do extremely advanced setups into something that your average joe can setup. This workflow for example would be near impossible for 99% of site owners to setup in segments in ECA: https://www.youtube.com/watch?v=1y2TicPyWZc&ab_channel=DrupalAIVideos. I'm also planning on building way more complex input/output modules like reading and writing to Powerpoint for instance, where knowing exactly how data comes in and out is of importance.

Also it was meant as an 100% automation tool outside of the CMS Drupal and rather used as a CMF for analytics dashboards - I just got the chance by nagging on my boss to open source it and since some people seems to like it I added some "normal" rules that "normal" Drupal websites needs :)

We will also build agents to it later, so you can control the workflows via Jira or Slack for instance - so once again not your "normal" way of doing Drupal. We basically saw that it was simpler to write a langchain-light in Drupal with all its great fields and field formatters already setup by the community, then building a tool around langchain in Python. So here we are :)

But with that said, they do work very well in tandem. For the AI Interpolator ECA v1.0 I have basically opted for the simple solution of having the full field rule be an ECA job, so you still get most of the power of ECA using it. There are improvements that can be done to this of course as well.

I also noticed that having a boolean interpolator without having the possibility to do any logic with it, is pretty meaningless :D

The one thing that will not work with right now, and also in field interpolation, do to me not having foresight of it is fallback rules. This will be added to AI Interpolator 2.0, since its feature breaking. For instance if you have an image field right now and want to search in Pixabay for a stock photo and the search word yields nothing the idea is that you can set a second rule for instance that generates an image instead. This would also open up for similar (and more complex) logic in ECA. But that will be in version 2.0.

The other thing is that it's very hard to show the whole complex field interpolation form on the ECA form at the moment, with how the ECA is currently working. From reading Slack messages it seems like ECA 2.0 will make this available.

But outside of those two things and for the current state - I would love to get feedback what is needed as feature tickets in the Issue Queue → of the module to get and idea what is needed to have it as a first version at least. If you have time and ideas there I would be super thankful for any feature or bug tickets you write (I saw one already!). It would be great to release something that is release candidate ready soon.

Thanks again!

Hi Marcus,

Thanks very much for the detailed background information. I'm very grateful for your ability to convince people to release AI Interpolator to the community; I use it daily. I think we look at it the same way, field-level is much more accessible to the general audience whereas ECA certainly comes with a learning curve attached. That's why I figured it might not hurt to have both methods available, but if the current UI inside ECA doesn't allow for the form complexity required by AI Interpolator to create rules then I see how that's a dealbreaker.

Things like fallback rules would be easily accomplished with ECA so maybe when 2.0 is released it can be worth considering.