>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3483356. --> Reported by: [marcus_johansson](https://www.drupal.org/user/385947) Related to !224 >>> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>Currently we have first class provider citizens being in the core module and second class providers being contributed, that in some cases are more advanced, leads to a disperity in what people knows to be available.</p> <p>Instead we should just let recipes solve the problems with wanting to pack a specific provider to a specific functionality or let the end user decide what kind of AI that want to solve a specific issue.</p> <p>We also have the problem that there are operation types that doesn't have a core module that supports them, which might be confusing - if you instead install specific providers for specific solutions it gets easier to understand.</p> <h4 id="summary-steps-reproduce">Steps to reproduce</h4> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <p>1. Move the providers to contributed modules.<br> 2. Pull them in temporarily using composer.json<br> 3. Make the modules empty, deprecated and let them have an update hook that updates the settings, installs the new module, uninstalls itself and clears cache.</p> <p>We shouldn't currently have any configuration dependencies on the actual module and since the plugin name will be the same this should work.</p> <h3 id="summary-remaining-tasks">Remaining tasks</h3> <h3 id="summary-ui-changes">User interface changes</h3> <h3 id="summary-api-changes">API changes</h3> <h3 id="summary-data-model-changes">Data model changes</h3>