AI SDK tool-loop recovery: check arguments, approval and history

When retrying preserves the failure

The September 30 Anthropic toolset report describes a call without a string action. Prompt conversion skips that call but retains its result. The next request contains a result whose matching call is absent, producing this reported error:

unexpected tool_use_id found in tool_result blocks

The reporter lists ai 7.0.122 and @ai-sdk/anthropic 4.0.68–4.0.69. Their workaround removes both halves and preserves the error as text. Reusing the same malformed history would preserve the cause of the failure; a retry alone would not repair it. This is a specific toolset-conversion report, not evidence that every invalid call has this behavior.

Proposed fix #21841 tracks skipped call IDs, omits matching results and avoids an empty result message. In the inspected converter at a39b2a2, that branch skips the result; it does not replace the error with explanatory text for the model.

That distinction matters when evaluating recovery: a request can become acceptable while losing information the model needs to correct its next call. Check both outcomes in your own application. Preserve a useful account of the failure without sending an orphaned result or exposing private arguments.

When unchanged input fails approval

The September 29 approval report concerns structurally unchanged JSON revived in another JavaScript realm. The reporter says constructor identity is compared before the fields, so a newly parsed object can be rejected despite matching keys and values:

Approved tool input does not match the validated schema output.

Their same-process control succeeds. The reported stack includes ai 7.0.122, @ai-sdk/workflow 2.0.53 and workflow 5.0.0-beta.57. This is different from a schema transform changing the approved operation. Do not treat every approval rejection as the same defect or disable approval checks to get past it.

Proposed fix #21810 changes deep comparison for cross-realm objects and arrays. The inspected change at 90a803f retains prototype checks outside that handling. The PR adds a regression test; that does not establish that your installed version contains the change.

Check the boundary before choosing the repair

Start in your affected project with a version inventory:

npm ls ai @ai-sdk/anthropic @ai-sdk/workflow workflow

Then inspect a minimal, redacted failing exchange:

1. Arguments: did the call reach completion, and do its inputs satisfy the tool schema? Parsing successfully is not the whole check.
2. Approval: does validation preserve the operation that was approved? Separate a real input change from a realm-sensitive comparison.
3. History: after provider conversion, does each result still have its required matching call? Check the outgoing request, not only the messages your application holds.

The official tool-calling documentation describes schema validation, approval handling and tool results. Use those contracts to narrow the failure before adding middleware. JSON serialization is not a universal equality repair; retrying is not a history repair.

At the stated check time, both proposed fixes were open and unmerged. Before relying on either, verify its merge, package release and behavior in your installed stack. No provider call, SDK test run or workflow execution was performed for this article. Keep real prompts, credentials and customer data out of public reproductions.