## Problem/Motivation Modules that drive an agent programmatically have no way to tag the chat calls the agent makes, which breaks `ai_logging` correlation for anything beyond "the whole run". `AiAgentEntityWrapper` builds a fixed tag set right before each provider call (`src/PluginBase/AiAgentEntityWrapper.php`, currently around line 536): ```php $tags = [ 'ai_agents', 'ai_agents_' . $this->aiAgent->id(), 'ai_agents_prompt_' . $this->aiAgent->id(), ]; if ($this->runnerId) { $tags[] = 'ai_agents_runner_' . $this->runnerId; } ``` There is no setter, constructor argument, or event that lets the caller append to this list. The same hardcoded pattern exists in `AiAgentBase` and `AgentHelper`. `AgentRequestEvent` fires with the `ChatInput`, but the tags are not on the event, so a subscriber cannot add any either. Concrete use case: `ai_answers` runs one agent call per conversation turn and wants its `ai_log` entries findable per `conversation:<uuid>` / `turn:<n>`, the way it tagged its direct provider calls before migrating onto `ai_agents`. Post-migration the best it can do is set a runner id up front and afterwards query for the newest `ai_agents_runner_<id>` entry. That loses per-round resolution (a run with tool calls writes one log entry per round; only the newest can be picked) and makes later re-correlation impossible (feedback given hours later can only use an id captured at answer time). Any other module embedding agents — chatbots wanting per-session tags, batch pipelines wanting per-item tags — hits the same wall. ## Proposed resolution Add a caller-supplied tag list to the wrapper, appended to the built-in tags: ```php public function setExtraTags(array $tags): void; ``` and in the tag construction: ```php $tags = array_merge($tags, $this->extraTags); ``` Mirror it wherever the hardcoded list is built (`AiAgentEntityWrapper`, `AiAgentBase`, `AgentHelper`) so plugin-based and config-based agents behave the same. Alternative/companion: expose the tags on `AgentRequestEvent` (getter + setter) so subscribers can adjust them per round without holding a wrapper reference. Either mechanism solves the use case; the setter is the simpler one for the common "caller owns the run" case. Happy to provide an MR if the approach sounds right. ## Remaining tasks - Agree on setter vs. event (or both). - MR + test coverage asserting a caller-supplied tag reaches the provider call. ## API changes One new public method on the wrapper (and/or two on `AgentRequestEvent`). Additive only.