fix: Remove status field from toolResult for non-claude 3 models in Bedrock model provider

[mehtarac]

Description

Removed the status field from the toolResult block for non claude-3 models in the Bedrock Model provider. This change is motivated by the linked issue. Furthermore, this change is supported by the bedrock documentation where it explicitly states that the status field is only supported in claude 3 models.

Related Issues

#554

Documentation PR

Type of Change

Bug fix

Testing

Script used to test:

from strands import Agent
from strands.models import BedrockModel
from strands_tools import calculator

## change the model-id to any foundation model enabled in your AWS Account
model = BedrockModel(
    model_id="us.anthropic.claude-opus-4-20250514-v1:0", #Or us.writer.palmyra-x4-v1:0
    temperature=0.3,
    streaming=False,
    region_name="us-west-2"
)

agent = Agent(
    model=model,
    tools=[calculator],
    system_prompt="You are an enterprise assistant that helps automate business workflows.",
)

response = agent("tell me what is square root of 64 times 2")

• I ran hatch run prepare

Checklist

• I have read the CONTRIBUTING document
• I have added any necessary tests that prove my fix is effective or my feature works
• I have updated the documentation accordingly
• I have added an appropriate example to the documentation to outline the feature, or no new docs are needed
• My changes generate no new warnings
• Any dependent changes have been merged and published

---

Sources:

• https://github.com/writer/aws-examples/blob/main/bedrock-examples/web-search-agent/agent.py
• https://aws.amazon.com/blogs/aws/writer-palmyra-x5-and-x4-foundation-models-are-now-available-in-amazon-bedrock/
  By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[mehtarac]

Note:

During my testing, I was able to test with multiple models and I had varying results in comparison with the issue reporter in #554. For example, I was able to get successful tool execution with the status field for models:

• anthropic.claude-3-7-sonnet-20250219-v1:0
• anthropic.claude-opus-4-20250514-v1:0

---

More interestingly, after this change I am seeing the model us.writer.palmyra-x4-v1:0 successfully execute tool calls. However, the model us.writer.palmyra-x5-v1:0 is running into an error below:

An error occurred (ValidationException) when calling the Converse operation: The model returned the following errors: {"body":{},"content_type":"application/json","metering":{"inputTokenCount":0,"outputTokenCount":0},"error":{"error_code":400,"error_msg":"Message at index 2 has empty or missing content"}}

I suspect the issue is that Writer Palmyra X4 and X5 have different tool calling implementations in Amazon Bedrock. Palmyra X4 properly supports tool results and can process toolResult blocks with just toolUseId and content fields, while Palmyra X5 appears to have a different tool calling implementation that fails to process tool results entirely, regardless of the field
structure. This suggests that Palmyra X5 either doesn't fully support the Bedrock Converse API's tool calling workflow or has a bug in its tool result processing that causes it to reject valid tool result messages.

[azaylamba]

I am able to use the status field with amazon.nova-pro-v1:0 as well.

[samjulien]

Hey @mehtarac thanks a lot for working on this. Out of curiosity, when did you run these tests with Palmyra X5? We swapped the version of X5 on Bedrock on Friday the 15th at some point. Could you retest if it was on or before that day and see if it changes anything?

EDIT: We were able to reproduce the issue on our side and have RCA'd it. There has been a fix provided upstream to AWS. Once AWS updates the container we should be good with this.

[dbschmigelski]

Do we need to modify this? It seems like globally we always want ToolResult to contain status - and consumers may depend on status being present.

Can we just perform the filtering within the bedrock when we send the data to bedrock without propagating the issue throughout our code.

Meaning if from a tool I want to pass a ToolResult, we internally still require status to be provided

[mehtarac]

Not sure I follow fully, but based on what I understand and experienced during testing -- there are some models available on bedrock that don't support the status field. In order to mitigate that, we do the filtering in bedrock.py. The change here to the type was needed to pass the linter where the status field is required in all cases. But since we have models that don't require status field, we don't require the status field. We DO return the status field for all models that accept the status field.

[Unshure]

I agree with @dbschmigelski here. ToolResult is the type that any result of a "StrandsTool" needs to return. If someone implements a custom tool, we want to require them to return the status field as part of the tools execution. We can leave this code unchanged, and still filter out status when calling bedrock.

Suggested change

	status: NotRequired[ToolResultStatus]
	status: ToolResultStatus

[samjulien]

Hey all, just to update: we've successfully updated Palmyra X5 on Bedrock and are seeing tool calling working as expected. Thank you for the catch on this! We are really hoping to be able to use Palmyra via Bedrock in Strands, so thanks for this.

[mehtarac]

Hey all, just to update: we've successfully updated Palmyra X5 on Bedrock and are seeing tool calling working as expected. Thank you for the catch on this! We are really hoping to be able to use Palmyra via Bedrock in Strands, so thanks for this.

Thank you for the fix @samjulien!!! I'll test the model again!

[Unshure]

I agree with @dbschmigelski here. ToolResult is the type that any result of a "StrandsTool" needs to return. If someone implements a custom tool, we want to require them to return the status field as part of the tools execution. We can leave this code unchanged, and still filter out status when calling bedrock.

Suggested change

	status: NotRequired[ToolResultStatus]
	status: ToolResultStatus