>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3610874. --> Reported by: [abhisekmazumdar](https://www.drupal.org/user/3557964) Related to !1 >>> <h2>Problem/Motivation</h2> <p><code>ai_assistant_api</code>'s own add/edit form already warns: "This assistant is using the old AI Assistant API for 1.0.0. Please create a new one and migrate the settings to the new one. The old one will be removed in 2.0.0."</p> <p><code>ai_answers</code> is built entirely on that API. <code>AssistantSettings</code> embeds its third-party settings form on the assistant entity. <code>AnswerService</code> and <code>RagSettingsResolver</code> read <code>system_prompt</code>, <code>instructions</code>, <code>llm_provider</code>/<code>llm_model</code>, and <code>actions_enabled.rag_action</code> directly off it. None of that survives the 2.0.0 removal as-is. This needs a plan now, not after 2.0.0 ships.</p> <h3>What's blocking the move today</h3> <p>The natural replacement is <code>ai_agents</code>: an <code>ai_agent</code> config entity with tools. <code>ai_answers</code> already reads a linked agent's <code>ai_search:rag_search</code> tool limits as one of its two RAG config shapes, but it doesn't run the agent's own execution engine, it just reads config off the entity.</p> <p>Moving the actual generation step onto <code>ai_agents</code>' execution engine (<code>AiAgentEntityWrapper</code>) costs the one feature <code>ai_answers</code> depends on for its chat UX: live token streaming.</p> <p>I traced <code>AiAgentEntityWrapper::determineSolvability()</code> end to end. The underlying <code>ai</code> core plus the OpenAI provider already fully support streaming with tool calls: <code>OpenAiChatMessageIterator</code> captures <code>delta.tool_calls</code> per chunk, and <code>StreamedChatMessageIterator::reconstructChatOutput()</code>/<code>getTools()</code> reassemble the complete tool-call-bearing <code>ChatOutput</code> once a stream ends. But <code>AiAgentEntityWrapper</code> never sets <code>$input-&gt;setStreamedOutput(TRUE)</code>. It always does a synchronous <code>$this-&gt;aiProvider-&gt;chat($input, ...)</code> then <code>-&gt;getNormalized()</code>. The gap is in <code>ai_agents</code>, not in <code>ai</code> core.</p> <p>This is already tracked: <a href="https://git.drupalcode.org/project/ai_agents/-/work_items/3538174">ai_agents #3538174 "Use streamed chat for agents"</a>, state::needsWork, with a draft MR <a href="https://git.drupalcode.org/project/ai_agents/-/merge_requests/165">!165</a> open against it.</p> <p>That MR adds <code>setStreaming(bool)</code> and sets <code>$input-&gt;setStreamedOutput($this-&gt;streaming)</code> on every round in <code>determineSolvability()</code>. It branches on <code>$response instanceof ChatMessage</code> for the existing synchronous path, versus a streamed iterator: <code>$response-&gt;addCallback([$this, 'postStreamingCallback']); $this-&gt;question = $response;</code>, handing the raw stream to the caller immediately and deferring tool-call and finish handling to the callback. <code>postStreamingCallback(ChatMessage $message)</code> runs once the stream ends: appends to chat history, checks <code>getTools()</code>, and calls <code>determineSolvability()</code> again for another round if tools were called and looping is enabled. It does not touch <code>BuildSystemPromptEvent</code>/<code>AgentStartedExecutionEvent</code> dispatch at all, so streaming and downstream system-prompt hooks aren't in tension.</p> <p>The gap that still looks open in !165: the single-round case, model streams straight to a final answer, looks solid. The case <code>ai_answers</code> would actually need, call the <code>rag_search</code> tool, get a result, then stream the final answer in the next round, doesn't look composed. Each round's stream is its own iterator object. <code>postStreamingCallback</code> triggers the next round's <code>determineSolvability()</code> internally, but nothing in the diff bridges that back to the original caller's in-progress stream consumption. Consistent with this still being needsWork and a draft, not merged.</p> <p>Worth knowing about in parallel, not a blocker for a read-only tool like <code>rag_search</code>, but a sign the whole tool-execution contract is moving underneath: <a href="https://git.drupalcode.org/project/ai_agents/-/work_items/3586020">ai_agents #3586020 "Per-tool approval mode (pre-approved / approve-once / always) with loop pause-resume"</a>, state::accepted, design stage, no MR yet, proposing a pause and resume gate before executing sensitive tools.</p> <h3>ai_context (Context Control Center), a related but separate integration</h3> <p><code>drupal/ai_context</code> gives an agent curated, scoped, site-specific knowledge, policy text, terminology, brand voice, per-content-type or per-entity notes, through <code>AiContextSystemPromptSubscriber</code>, which listens to <code>AgentStartedExecutionEvent</code> and <code>BuildSystemPromptEvent</code>. Those are the same events <code>AiAgentEntityWrapper::determineSolvability()</code> dispatches today, streaming or not per !165's diff. Its handler hard-requires an agent id (<code>if (!$agentId || !$prompt) { return; }</code>), so it only fires for a real <code>ai_agents</code> execution, never for <code>ai_answers</code>'s current direct <code>$provider-&gt;chat()</code> call.</p> <p>Two ways this integrates, not mutually exclusive:</p> <ol> <li>Automatic, once the agents migration lands. If <code>ai_answers</code> moves generation onto <code>AiAgentEntityWrapper</code>'s own loop, <code>ai_context</code>'s injection happens for free through those events.</li> <li>Manual, independent of the agents migration. <code>AnswerService::buildSystemPrompt()</code> already assembles the citation contract, assistant prompt, and sources block by hand. It could call <code>ai_context</code>'s own services (<code>ai_context.selector</code>/<code>ai_context.renderer</code>) directly, the same optional-soft-dependency pattern already used for <code>ai_logging</code> and <code>langfuse</code> (<code>$this-&gt;moduleHandler-&gt;moduleExists(...)</code>). Works today, no agents migration required, doesn't come free.</li> </ol> <p>But I feel we go with the 1st approach.</p> <h2>Proposed resolution</h2> <p><strong>Path A.</strong> Wait for or contribute to <code>ai_agents</code> #3538174 landing, then migrate <code>ai_answers</code>'s generation step onto <code>AiAgentEntityWrapper</code>, with RAG retrieval becoming an actual tool call, reusing <code>ai_search</code>'s existing <code>rag_search</code> tool, instead of the current direct <code>retrieve()</code> call. Gets streaming and automatic <code>ai_context</code> injection together, once merged. Depends on someone else's timeline, and on the multi-round stream-chaining gap in !165 actually getting resolved.</p> <h2>Remaining tasks</h2> <ul> <li>Do <code>ai_agents</code> #3538174 and MR !165, review or test and move it forward.</li> </ul> <h2>User interface changes</h2> <p>None yet, this is planning.</p> <h2>API changes</h2> <p>None yet.</p> <h2>Data model changes</h2> <p>None yet.</p>