> ⚠️ **Postponed pending approval.** Part of the [Chat Fundamentals plan](https://git.drupalcode.org/project/ai/-/work_items/3586640); awaits maintainer approval ([approval issue](https://git.drupalcode.org/project/ai/-/work_items/3586639)). Targets the **1.6.x branch once it is created**. **Depends on:** [content blocks + `_meta` conventions (#3586643)](https://git.drupalcode.org/project/ai/-/work_items/3586643); shares the interface-evolution pattern with the structured-response child issue and can be developed in parallel with it. ### Problem/Motivation There is no way for a processor — or an agent running beneath it — to ask the user a structured question mid-task. The only interaction primitive is a full chat message, so "which of these three nodes did you mean?", "give me a title and a date for the event", and "really delete 10 entities?" all have to be improvised as free-text exchanges the model must parse back out. Forms-in-chat and safe tool confirmation are impossible to do in a frontend-agnostic way. MCP defines exactly this primitive: **elicitation** (spec 2025-06-18). The server sends `{message: string, requestedSchema: {...}}`; the client answers `{action: "accept" | "decline" | "cancel", content?: {...}}`. The `requestedSchema` is deliberately restricted to a **flat object of primitives** — `string` (with optional `format: email|uri|date|date-time`, min/maxLength), `number`/`integer` (min/max), `boolean` (default), and enums (`enum` + `enumNames`). No nesting, no arrays, no file uploads. That restriction is precisely what makes elicitation safely frontend-agnostic: any client can render it with five widget types. ### Proposed resolution **Value objects** in `src/OperationType/Chat/Elicitation/`: - `ElicitationRequest` — `id` (UUID), `message`, `requestedSchema` (validated against the flat-primitive restriction on construction), `_meta`; `toArray()` emits the MCP `elicitation/create` params shape with the ID under `_meta['drupal.org/ai.elicitation_id']`. - `ElicitationResult` — `elicitationId`, `action` (enum `ElicitationAction: Accept | Decline | Cancel`), `content` (array, validated against the request schema on `accept`). **ChatProcessor contract** (defaults in `ChatProcessorBase`, same evolution pattern as the structured-response child issue): - `getPendingElicitation(): ?ElicitationRequest` — non-null when the turn ended by asking the user something. - `setElicitationResult(ElicitationResult $result): void` — supplied by the consumer before re-executing. **Round-trip protocol**, built on machinery that already exists (`setFinished()` + per-thread tempstore, per the `ai_assistant_threads` precedent in ai_assistant_api): 1. During `execute()`, something below the processor raises an elicitation. The processor persists its paused state under the thread ID, ends the turn, and exposes the request via `getPendingElicitation()`. 2. The consumer renders it — a form built from `requestedSchema`, or a confirm dialog when the schema is trivial — in whatever way suits the frontend. 3. The frontend posts the result; the consumer constructs an `ElicitationResult`, calls `setElicitationResult()` on a fresh processor instance with the same thread ID, then `execute()`. The processor resumes from persisted state. 4. **Idempotency and expiry:** the `elicitationId` guards double-submits (a result for an unknown or already-consumed ID is rejected); unresolved elicitations expire with the tempstore entry. **Widget hints — extension without schema mutation:** richer Drupal widgets ride request-level `_meta['drupal.org/ai.widgets']`, keyed by property name, e.g. ```json {"node": {"widget": "entity_autocomplete", "target_type": "node", "bundles": ["article"]}} ``` The property itself stays `{type: "string"}` and the submitted value is an entity ID/UUID string. A dumb frontend renders a text field; nothing breaks. Registered in the `_meta` key registry (#3586643). **Documented limits:** no nested forms, no arrays/multi-value, no uploads — embedding full Form API in chat is a different feature, and the flat restriction is *why* this one is portable. Multi-select is the most painful gap; noted as a known limitation with a possible future `drupal.org/ai.multiple` hint (comma-separated string value) rather than a schema deviation. **Tests:** unit tests for schema validation (accept flat primitives, reject nesting/arrays), result validation against the request schema, and action semantics; kernel test simulating pause → result → resume across two processor instantiations on one thread. ### Backwards compatibility Additive interface methods via base defaults; new value objects. No existing flow changes until a processor raises an elicitation. **Consumer integration note:** a consumer that ignores `getPendingElicitation()` degrades gracefully — the turn simply ends with the processor's text (which should restate the question in prose). ### AI Assistance Yes, AI was used to explore the codebase and draft this issue.