> ⚠️ **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 branches of ai and ai_agents once created**. Opt-in. **Depends on:** the [meta plan's conventions](https://git.drupalcode.org/project/ai/-/work_items/3586640); soft-depends on the [`_meta` key registry (#3586643)](https://git.drupalcode.org/project/ai/-/work_items/3586643). Independent of the ChatProcessor child issues. ### Problem/Motivation ai_agents already produces a rich, typed status stream: `AiAgentStatusItemTypes` (`agent_started`, `agent_iteration`, `tool_selected`, `tool_started`, `tool_finished`, `ai_provider_request`, `ai_provider_response`, `text_generated`, `system_message`) written to `PrivateTempStatusStorage` and served by `AiAgentStatusPollerService`. But the only thing that renders it is ai_agents_debugger — an admin-only React app. End users of any chatbot stare at a dead spinner during a long agent run, even though tool-level progress data already exists server-side, per thread. MCP defines a progress shape (spec 2025-06-18): `notifications/progress` with params `{progressToken, progress, total?, message?}`, where `progress` increases monotonically and the token correlates the notification to the original request. We have no JSON-RPC session, but the polling thread ID is the natural `progressToken` analog. ### Proposed resolution Adopt the **params object shape, not the JSON-RPC envelope**, and deliver it over the existing polling channel: - New service `AgentStatusProgressNormalizer`: converts stored status items for a thread into an ordered list of MCP progress params: ```json { "progressToken": "<thread id>", "progress": 7, "total": null, "message": "Running tool: entity_search", "_meta": {"drupal.org/ai.status_item": {"type": "tool_started", "...": "..."}} } ``` `progress` is a monotonic counter over emitted items (`total` only when the agent can bound its iterations); `message` is a short human-readable line derived from the typed item; the full typed payload rides `_meta['drupal.org/ai.status_item']` for consumers that want structured detail (registered in the `_meta` key registry, #3586643 on the ai project). - Expose it through the existing poller service so **any** consumer — not just the debugger — can request progress for a thread it owns. Access follows the same private-tempstore ownership the status storage already enforces. - **Opt-in** per assistant/agent (config flag); default off, so no site pays the storage/normalization cost unasked. - **Progress is transport, not payload:** it is ephemeral, never persisted into message history, and never attached to `ChatMessage` content blocks. It expires with the status storage. **Tests:** kernel test asserting normalization of a representative item sequence (monotonicity, message derivation, `_meta` payload), the opt-in flag, and that another user's thread yields nothing. ### Backwards compatibility New service and opt-in flag only. The debugger keeps consuming the raw typed stream unchanged. **Consumer integration note:** a chatbot that already polls for continue-style loops can fetch progress in the same tick and render `message` as the loading line — no new connection type required. ### AI Assistance Yes, AI was used to explore the codebase and draft this issue.