## Summary This came out of CCC QA work: #3586226+ and #3586440+ When an AI Assistant is configured to run an agent, the page context sent by the frontend never reaches anything. Classic (non-agent) assistants pass the same context into the system prompt, so this is an asymmetry between the two assistant modes rather than a missing feature. `AgentRunner::runAsAgent()` packages the context into `AiAssistantPassContextToAgentEvent`, dispatches it, and then never reads it back. No subscriber to that event exists anywhere in contrib. ## Steps to reproduce 1. Install `ai`, `ai_assistant_api`, `ai_chatbot` (DeepChat) and `ai_agents`. 2. Create an AI Assistant and set its "AI agent" field so it runs as an agent. 3. Place the AI DeepChat Chatbot block, and view any node page. 4. Ask the chatbot which page or node you are currently on. 5. Confirm in the browser network tab that the POST to `/api/deepchat` includes `contexts: {current_route: "/node/2"}`. ## Expected result The agent has access to the current route, the same way a non-agent assistant does, so route- or entity-dependent behavior works. ## Actual result The agent has no page awareness. Depending on conversation state the model guesses a node, fabricates a node ID that does not exist on the site, or states that the route was not provided — while `current_route` was present in the request payload. ## Evidence Verified path (all hops present and correct until the last one): ```text DeepChatFormBlock::getDeepChatParameters() sets contexts.current_route from currentPath->getPath() DeepChatApi::api() calls $this->aiAssistantClient->setContext($data['contexts']) AiAssistantApiRunner::process() agent branch: runAsAgent(..., $this->getContext()) AgentRunner::runAsAgent() dispatches AiAssistantPassContextToAgentEvent, then calls $agent->determineSolvability() -- $event->getContext() is never read no subscriber ``` The only references to `AiAssistantPassContextToAgentEvent` in contrib are the event class, `AgentRunner`, and `phpstan.neon`. By contrast, the non-agent path in `AiAssistantApiRunner` passes `$this->context` into `AssistantMessageBuilder::buildMessage()`, where it is used. Because nothing reads the event after dispatch, a subscriber that only calls `$event->setContext()` would be a no-op. The usable handle is `$event->getAgent()`. ## Observable Symptoms These were all reproduced and documented during QA test: * On `/node/2`, the assistant answered **"This is node 1"** — despite `contexts.current_route: "/node/2"` being verifiably present in the request payload (captured in DevTools Network tab). * On subsequent attempts (clean thread), the assistant answered **"This is node 72"** — a node that does not exist on the site. This rules out a hardcoded config value; the model is fabricating. * After clearing the conversation history (eliminating accumulated context bias), the assistant answered **"I can't identify the current node because the page route wasn't provided"** / **"I don't have access to the current page route"** — which is what you'd expect when a model honestly reports having no route data, even though the data was in the request. All three answers are consistent with the model having no real page information at all, and falling back on guessing, fabrication, or honest denial depending on conversation state. ## Environment (QA) * Drupal version: 11 * Module version: `drupal/ai dev-1.4.7`, `ai_agents 1.3.4` * PHP version: 8.4 * Provider: OpenAI {width="900" height="184"} ## Related issues Surfaced during Context Control Center QA in #3586440+s, where it made all entity- and path-dependent context scopes non-functional for chatbot traffic. ## AI disclosure - [x] AI assisted issue