fix: result_as_answer should not apply to tool errors

[r266-tech]

Closes #5156

Problem

When a tool with result_as_answer=True encounters an error, the error message is unconditionally returned as the agent's final answer. This prevents the agent from reflecting on the error and potentially retrying.

For example, a code execution tool with result_as_answer=True that raises SyntaxError would produce:

Error executing tool: SyntaxError('invalid syntax')

as the final agent output — instead of letting the agent see the error and try to fix it.

Root Cause

_append_tool_result_and_check_finality() checks result_as_answer=True unconditionally:

if (
    original_tool
    and hasattr(original_tool, "result_as_answer")
    and original_tool.result_as_answer
):
    return AgentFinish(...)  # Always returns, even on error

There is no distinction between successful tool outputs and error results.

Fix

Track an is_error flag through _execute_single_native_tool_call() and check it before returning AgentFinish.

Error paths (is_error=True):

• JSON parse failure in tool arguments
• Tool not found
• Hook blocked execution
• Max usage limit reached
• Exception during tool execution

Success paths (is_error=False):

• Cached result available
• Tool executed successfully

The check becomes:

if (
    not is_error
    and original_tool
    and hasattr(original_tool, "result_as_answer")
    and original_tool.result_as_answer
):
    return AgentFinish(...)

When is_error=True, the method returns None, allowing the agent loop to continue and let the LLM reflect on the error.

1 file changed, +10/-1

---

Note

Medium Risk
Changes the native tool-calling finalize logic so error outputs no longer short-circuit the agent loop; this can alter when agents stop vs. retry/reflect, impacting behavior for tools relying on result_as_answer. Logic is localized but affects core execution flow for tool calls.

Overview
Prevents tools with result_as_answer=True from returning error outputs as the agent’s final answer during native tool calling.

The executor now propagates an is_error flag from _execute_single_native_tool_call() (covering parse failures, missing tools, hook blocks, usage-limit blocks, and exceptions) and adds a heuristic _looks_like_tool_error() check, so _append_tool_result_and_check_finality() only returns AgentFinish for successful tool results.

^{Written by Cursor Bugbot for commit c273dff. This will update automatically on new commits. Configure here.}

[r266-tech]

Good catch! Added is_error = True to the hook_blocked and max_usage_reached branches to handle the cache-hit-then-blocked edge case.

[Vamshi3130]

what if tool returns string of error instead of raise an exception as shown in documentation and i belive currently being followed in all builtin tools

[r266-tech]

Good catch! Many built-in tools (brave_search, rag, aws/s3, ocr) return error strings like "Error performing search: ..." without raising exceptions. I've added a _looks_like_tool_error() static method as a fallback:

• Detects "Error ..." prefix (most built-in tools)
• Detects "I encountered an error ..." (tool_usage.py i18n messages)

So now both cases are covered: (1) is_error flag for exception/parse failures, (2) string-based detection for tools that return error strings.

The PR has been updated with the additional commit.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[cursor]

Error prefix misclassifies valid tool outputs

Medium Severity

The new result_as_answer guard treats any successful result starting with Error or I encountered an error as a failure via _looks_like_tool_error. Legitimate outputs with those prefixes are now prevented from finalizing in crew_agent_executor.py, changing behavior for valid result_as_answer tools.

Additional Locations (1)

• lib/crewai/src/crewai/agents/crew_agent_executor.py#L1128-L1140