[gingeekrishna]

Summary

• _filter_restored_tool_context() stripped toolUse/toolResult blocks from restored session history but left reasoningContent (extended thinking) blocks intact.
• Bedrock rejects an assistant message where reasoningContent blocks are present without their companion toolUse blocks, raising a ValidationException.
• Fix: add "reasoningContent" not in content to the filter predicate so thinking blocks are stripped together with the tool calls they preceded.

Root cause

When extended thinking is enabled, an assistant turn produces a message like:

{
  "role": "assistant",
  "content": [
    {"reasoningContent": {"reasoningText": {"text": "…"}}},
    {"toolUse": {"toolUseId": "t1", "name": "my_tool", "input": {}}}
  ]
}

reasoningContent and toolUse are semantically coupled — the Bedrock API requires them to appear together. filter_restored_tool_context was removing toolUse while keeping reasoningContent, producing a partial message that the API refuses.

Test plan

• test_strips_reasoning_content_alongside_tool_use — assistant message with reasoningContent+toolUse → both stripped, only plain-text assistant message survives
• test_message_with_only_reasoning_and_tool_use_is_dropped_entirely — message becomes empty after stripping → excluded from output
• test_text_alongside_reasoning_and_tool_use_is_preserved — text content survives after stripping reasoning+toolUse
• test_messages_without_tool_context_are_unchanged — plain text messages pass through unchanged (no regression)
• test_existing_tool_use_filtering_still_works — original toolUse/toolResult behaviour preserved

5 passed in 0.XXs

Fixes #621

[Copilot]

Pull request overview

This PR fixes restored-session filtering for Bedrock extended thinking by ensuring reasoningContent blocks are removed alongside toolUse/toolResult blocks, preventing invalid assistant messages from being sent to Bedrock.

Changes:

• Update _filter_restored_tool_context() to also strip reasoningContent blocks when filtering restored history.
• Expand the session manager integration test suite with regression cases covering reasoning+tool interactions and preservation of plain text.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
tests/bedrock_agentcore/memory/integrations/strands/test_agentcore_memory_session_manager.py	Adds regression tests validating restored-history filtering when reasoningContent is present.
src/bedrock_agentcore/memory/integrations/strands/session_manager.py	Extends restored tool-context filtering to remove reasoningContent blocks and documents the rationale.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[gingeekrishna]

Done - addressed Copilot review: updated the filter_restored_tool_context docstring in AgentCoreMemoryConfig (commit d4f9b5d) to clarify that it strips toolUse, toolResult, and reasoningContent (extended thinking) blocks, with a note explaining that reasoning blocks must always be removed alongside the tool calls that followed them.

[art-aws]

Independent confirmation from a different model generation, plus one case the tests do not pin down.

Reproduction, Claude Haiku 5.5 (adaptive thinking on by default), bedrock-agentcore 1.13.0. Same ValidationException as #621 on the second turn of any restored session with filter_restored_tool_context=True. We carry a workaround in production that wraps _filter_restored_tool_context and additionally drops reasoningContent, with the same predicate this PR adds; it has been running in SMART, the Social Messaging Agent Runtime Toolkit (awslabs/social-messaging-agent-runtime-toolkit, public release this month), since 2026-10-09 with no regressions on Haiku 4.5 histories, where it is a no-op.

The root cause is broader than tool coupling. The PR's docstring and all five tests frame reasoningContent as paired with a following toolUse. The API constraint is actually that a thinking block is bound to the exact context it was produced in, and is rejected on replay if anything before it changed. Stripping tool blocks is one such change, but so is a system prompt that differs between turns (ours includes the current time), and that invalidates reasoning blocks in text-only assistant turns with no toolUse at all. The predicate in this PR handles that case correctly because it strips every reasoningContent; the tests do not exercise it, so a future reviewer could narrow the strip to "only when paired with toolUse" and reintroduce the failure.

Suggested addition: one test where an assistant message is [reasoningContent, text] with no tool blocks, asserting the result is [text]. And a one-line docstring change from "coupled to the tool calls" to "bound to the context they were produced in; any edit to earlier history, including this filter's own tool stripping, invalidates them."

Happy to open that as a follow-up commit on this branch if useful. This fix is the right shape and we would like to drop our wrapper once it ships.

[gingeekrishna]

@art-aws thanks for the independent confirmation and the sharper framing -- you're right that the real invariant is "bound to the context it was produced in," not "coupled to the following tool call." Done in eff72ee:

• Reworded the docstring to say reasoningContent is invalidated by any earlier change to history (including this filter's own tool stripping), not just a missing companion toolUse.
• Added test_strips_reasoning_content_with_no_tool_blocks: an assistant message [reasoningContent, text] with no tool blocks at all, asserting the result is [text].

The implementation was already correct for your text-only case (it strips reasoningContent unconditionally), so this closes the gap you flagged where a future reviewer could otherwise "fix" it into only stripping when paired with a tool and silently reintroduce the failure. All 188 tests in the file pass.

Glad to hear this lets you drop the SMART wrapper once it ships.