>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3577243. --> Reported by: [marcus_johansson](https://www.drupal.org/user/385947) >>> <p>[Tracker]<br> <strong>Update Summary: </strong>[One-line status update for stakeholders]<br> <strong>Short Description: </strong>Add required provider lifecycle events (setup/disabled/uninstalled) and explore architecture to enforce them<br> <strong>Check-in Date: </strong>MM/DD/YYYY<br> [/Tracker]</p> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>The AI module currently exposes events when a provider is enabled or configured, but emitting these events is optional for provider implementers. Because of this, other systems depending on providers (such as AI Agents, default AI configuration, or installation setups) cannot reliably react to provider lifecycle changes.</p> <p>A common problem occurs when a provider is disabled or uninstalled. Systems that depend on the provider (agents, stored configuration, automation rules, etc.) are not notified and therefore cannot clean up, warn users, or switch to fallback providers.</p> <p>Provider lifecycle events should therefore be standardized and reliably emitted whenever a provider is configured, disabled, or uninstalled. Ideally, this should not rely on each provider author manually dispatching events, as that leads to inconsistent behavior across providers.</p> <p>The architecture should ensure that lifecycle events are triggered centrally and consistently so other modules can depend on them.</p> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <ul> <li>Introduce standardized provider lifecycle events such as ProviderConfiguredEvent, ProviderDisabledEvent, and ProviderUninstalledEvent.</li> <li>Ensure these events are dispatched from a central place in the AI module rather than relying on provider implementations to trigger them manually.</li> <li>Investigate enforcing lifecycle dispatch through the provider manager or provider base class so all providers automatically trigger the events.</li> <li>Example architecture option: dispatch events inside the provider manager when providers are enabled, disabled, or removed through configuration changes.</li> <li>Example architecture option: add lifecycle methods in the provider base plugin class (for example onProviderConfigured(), onProviderDisabled(), onProviderUninstalled()) which internally dispatch events.</li> <li>Example architecture option: detect configuration changes to provider configs and emit events based on config create/update/delete operations.</li> <li>Ensure dependent systems such as AI Agents, setups, and default configuration listeners can subscribe to these lifecycle events.</li> <li>If enforcing this behavior generically across all providers is not possible without breaking extensibility, research alternative architectures that still guarantee reliable lifecycle notifications.</li> </ul> <h3 id="summary-ai-usage">AI usage (if applicable)</h3> <p>[x] AI Assisted Issue<br> This issue was generated with AI assistance, but was reviewed and refined by the creator.</p> <p>[ ] AI Assisted Code<br> This code was mainly generated by a human, with AI autocompleting or parts AI generated, but under full human supervision.</p> <p>[ ] AI Generated Code<br> This code was mainly generated by an AI with human guidance, and reviewed, tested, and refined by a human.</p> <p>[ ] Vibe Coded<br> This code was generated by an AI and has only been functionally tested.</p> <p>- <strong>This issue was created with the help of AI</strong></p>