Ramnique Singh 15567cd1dd let tool failures be observed by the model instead of killing the run ... streamAgent executed tools with no try/catch around the call. A throw from execTool or from a subflow agent streamed up through streamAgent, out of trigger's inner catch (which rethrows non-abort errors), and into the new top-level catch that the previous commit added. That surfaces the failure — but it ends the run. One misbehaving tool took down the whole conversation. Wrap the tool-execution block in a try/catch. On abort, rethrow so the existing AbortError path still fires. On any other error, convert the exception into a tool-result payload ({ success: false, error, toolName }) and keep going. The model then sees a tool-result message saying the tool failed with a specific message and can apologize, retry with different arguments, pick a different tool, or explain to the user — the normal recovery moves it already knows how to make. No change to happy-path tool execution, no change to abort handling, no change to subflow agent semantics (subflows that themselves error are treated identically to regular tool errors at the call site). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>		2026-04-21 14:38:19 +05:30
..
core	let tool failures be observed by the model instead of killing the run	2026-04-21 14:38:19 +05:30
shared	add prompt block	2026-04-20 14:42:13 +05:30