[#3574187] introduced symfony/ai component in v0.6. Meanwhile 0.8 has been released, introducing its own provider abstraction: a symfony [ProviderInterface](https://github.com/symfony/ai/pull/1923). Based upon @mxr576's [plan](https://git.drupalcode.org/project/ai/-/work_items/3574187#note_809810), we want to adopt the new abstraction in this issue. Overview over the concepts, citing the Symfony PR: > **ProviderInterface** encapsulates what PlatformFactory::create() currently produces — a complete, self-contained connection to a single inference backend (model clients, result converters, contract, catalog). > **Platform** becomes a thin routing layer over multiple providers, using a ModelRouterInterface to determine which provider handles each request. Therefore, we'll refer to _legacy AI providers_ of Drupal AI module and simply _AI providers_ (Symfony) to differentiate. ### Naming collision Code-wise, the plan is to resolve the naming issue with namespaces: ``` Plugin/ai/Provider/ ← 2.x Provider plugins (via Symfony) Plugin/ai/Platform/ ← 2.x Platform plugins Plugin/ai/ModelRouter/ ← 2.x ModelRouter plugins ``` Citing @mxr576's [plan](https://git.drupalcode.org/project/ai/-/work_items/3574187#note_809810): > This lets us use natural names without colliding with the existing `Plugin/AiProvider/` directory from 1.x. Both can coexist in the same codebase during the deprecation window, which matters because we intend to ship a forward compatibility layer in 1.x. The goal of that forward compat layer is to let contrib module developers start migrating their code against 1.x today, so that when 2.0 ships they can simply drop 1.x support and remove deprecated code. This means the old and new plugin infrastructure must be able to coexist in the same 1.x codebase simultaneously. ### Implementation plan The plan is to have the following structure, summary: - Two layers: `Provider` plugins sit below `Platform`, mapping to the new `ProviderInterface` / `PlatformInterface` split. The existing platforms continue to exist, they just gained a layer below it. - Two config entities and plugin types: - `AI Provider`: config entity + plugin type (new, Symfony) - `AI Platform`: config entity + plugin type. Referring to providers. - `AiPlatformModelRouter`: plugin type only (routes model name → provider) - Consumers reference a platform, not a provider directly. Citing @mxr576 again: > Consumers (agents, chat, search, embeddings) reference an `AiPlatform` config entity by machine name and receive a `PlatformInterface` instance. They never depend on `AiPlatformProvider` or `AiPlatformModelRouter` directly. Factories and factory methods such as `ProviderFactory::create()` and `createPlatform()` are intentionally not surfaced in Drupal. Plugin instances and config entities serve that purpose. **Platform -> Providers** Routing strategy is always specific to a given `AiPlatform` setup, so no standalone config entity is needed. Config lives inside the `AiPlatform` plugin's config blob. Ships with a default `CatalogBasedAiPlatformModelRouter` wrapping Symfony's `CatalogBasedModelRouter`. --- **UI implications** - We don't necessarily want to surface the extra-layer of config entities in the UI. Potentially the new Platform-layer could merge with operation types. This part needs more planning.