## Summary Add an **Agents & Tools** tab to the Canvas AI settings area where an admin picks the **main agent** (single select) and the **Tools** offered in the chat (checkboxes), and expose the selected Tools to the frontend as `drupalSettings.canvas.ai.tools`. The form, its route and its config all live in `canvas_dev_ai`. Nothing in `canvas_ai` changes. ## Why In the revamped flow, agent selection is config-driven and explicit — the user picks the agent for the turn from a dropdown instead of an orchestrator inferring it (roadmap item 2: https://git.drupalcode.org/project/canvas/-/work_items/3591777). That dropdown (https://git.drupalcode.org/project/canvas/-/work_items/3591856) reads its list from `drupalSettings.canvas.ai.tools`, which today is populated by nothing. This issue is the backend half that fills it. ## Current behavior `/admin/config/ai/canvas-ai-settings` has three tabs — General Settings, Component Descriptions, Page Region Descriptions (`canvas_ai.links.task.yml`). There is no way to choose which agent answers a chat turn: the live controller hardcodes the orchestrator, and the dev controller returns a mock and runs no agent at all. ## Proposed Everything below lands in `canvas_dev_ai`. ### The form `CanvasDevAiAgentSelectionForm`, a `ConfigFormBase` on its own route, registered as a fourth local task with `base_route: canvas_ai.setting` and a weight after the existing three. `CanvasAiComponentDescriptionSettingsForm` (the "Component Descriptions" tab) is the pattern to follow — same shape, same routing, contributed from the dev module. - **Main agent** — a required `select`. - **Tools** — `checkboxes` over the same list. - **Validation** — an agent selected as the main agent cannot also be selected as a Tool. Both element lists are built by loading the `ai_agent` config entities and filtering to three: `canvas_ai_orchestrator`, `component_agent` and `canvas_page_builder_agent`. Defaults: `canvas_ai_orchestrator` as the main agent, `component_agent` and `canvas_page_builder_agent` as Tools. ### What config stores Config stores **only the agent IDs** — the main agent, and the list of selected Tools. Labels and descriptions are read from the `ai_agent` entities at runtime; they are not copied into config, where they would go stale as soon as an agent is edited. ### Exposing the Tools to the frontend `CanvasDevAiHooks::jsSettingsAlter()` builds the full objects the dropdown expects, under the same `aiExtensionAvailable` guard as the existing `aiDevMode` flag: ```json [ { "id": "canvas_page_builder_agent", "label": "Page builder", "description": "Builds and edits page layouts." } ] ``` - `label` and `description` come from each `ai_agent` entity. **The main agent is not sent to `drupalSettings`.** The dev controller loads it from config and invokes it directly for turns with no active Tool; that is a separate issue and out of scope here. ### Moving to canvas_ai later Once the functionality is complete, this form moves into `canvas_ai`: the form class, its route and its local task, along with the tools-emitting block in `CanvasDevAiHooks::jsSettingsAlter()`, and the stored values move into `canvas_ai.settings` with a `hook_update_N`. That update must run before `canvas_dev_ai` is uninstalled, since uninstalling a module deletes the config objects prefixed with its name. ## Tests New test classes in `canvas_ai`, which is where the dev module's coverage lives. `modules/canvas_ai/tests/src/Kernel/CanvasAiDevControllerTest.php` covers the dev controller only — do not add to it; its `testAiDevModeFlagFollowsInstallState()` is a useful example of installing and uninstalling `canvas_dev_ai` and reading the altered JS settings. New kernel test: - Installing `canvas_dev_ai` makes the **Agents & Tools** local task available under the Canvas AI settings route. - With Tools selected, `drupalSettings.canvas.ai.tools` lists exactly those Tools, each with its `id` and the `label` and `description` loaded from the `ai_agent` entity. - No key is emitted when no Tools are selected. - Uninstalling `canvas_dev_ai` removes the config object, the `canvas.ai.tools` key and the local task. New functional test, alongside the existing settings-form tests in `modules/canvas_ai/tests/src/Functional/Form/`: - The tab renders and saves both values. - A submission selecting the same agent as the main agent and as a Tool is rejected with a validation error. Manual: install `canvas_dev_ai`, select a main agent and some Tools on the new tab, open the Canvas editor and check `drupalSettings.canvas.ai.tools` in the browser console — it lists exactly the selected Tools, each with its id, label and description, and no main agent. ## Explicitly out of scope - The dropdown UI itself (https://git.drupalcode.org/project/canvas/-/work_items/3591856). - Backend handling of the `tools` request parameter, and loading and invoking `main_agent` for a turn — the dev hop-controller issue. - Any change to `canvas_ai` beyond the new tests: no new schema keys, no form alter, no behavior change. - A Q&A agent option (roadmap item 9, not built yet). _Issue generated with AI assistance._