**Problem/Motivation** When an LLM sends an invalid input value (e.g. a text format that is not a valid choice on the site), the connector's input stage fails before the wrapped Tool plugin ever executes. The connector handles this gracefully — `errorMessage` is set and `getStructuredOutput()` returns a failure with the input schema so the LLM can self-correct. However, consumers that read the tool's result directly are not protected: ai_agents' image collection loop (`AiAgentEntityWrapper`) calls `getPluginInstance()->getResult()` without checking `hasResult()`. On an un-executed tool this throws: > The action result cannot be retrieved until the action ::execute() method has been called. The exception aborts the entire agent run and the LLM never receives the corrective failure message. One invalid argument kills the whole workflow instead of costing one retry round. **Steps to reproduce** 1. Run an agent with tool_belt's field_set_value against a site that lacks the text format the LLM guesses (e.g. full_html). 2. The tool fails input validation in \~0.01s; the run then dies with the BadMethodCallException above instead of the LLM retrying. **Proposed resolution** - Add `ToolInterface::setFailureResult(TranslatableMarkup $message)`: records a failure result on a tool that never executed. Throws `\LogicException` if a result already exists, so a real execution result can never be overwritten. - Add `ToolInterface::hasExecuted()`: distinguishes "a result exists" (`hasResult()`) from "execute() actually ran", so retry logic and telemetry keep the distinction. `hasResult()` documentation updated accordingly. - The AI connector calls `setFailureResult()` whenever its execute() ends with an error and the wrapped tool has no result (input failure, access denial). `getResult()`'s exception contract for genuine caller errors is unchanged. The root cause is also an ai_agents bug — its `getResult()` call should be guarded by `hasResult()` — and will be reported upstream separately. This change is correct independent of that fix: "failed before execution" is a real state that any invoker (AI, Drush, MCP) can legitimately need to record. **API changes** Two new methods on `ToolInterface`: `setFailureResult()` and `hasExecuted()`. Additive; existing implementations extending ToolBase get them for free.