Problem
The AgentCore Harness runtime internally constructs a BedrockModel (Strands SDK) without exposing the boto_client_config parameter to customers. The default read_timeout of 120 seconds is insufficient for agents with complex tool chains where accumulated context causes time-to-first-token (TTFT) to exceed 120s.
Impact
- 100% failure rate on our security reviewer agent (Sonnet 4.5, 8 gateway tools)
- 56 timeout events across 7 invocations in 24 hours
- Any agent requiring >3-5 tool call cycles is at risk
- Model confirmed via OTel metrics:
global.anthropic.claude-sonnet-4-5-20250929-v1:0
- Even Sonnet 4.5 (not just Opus) times out when context grows from accumulated tool results
Root Cause
From strands/models/bedrock.py:
DEFAULT_READ_TIMEOUT = 120
# If boto_client_config is NOT passed (harness default path):
client_config = BotocoreConfig(user_agent_extra="strands-agents", read_timeout=DEFAULT_READ_TIMEOUT)
The Harness constructs BedrockModel without customer-controlled boto_client_config, so there's no way to increase read_timeout.
Stack Trace (from CloudWatch)
strands/event_loop/event_loop.py:238 → event_loop_cycle
strands/event_loop/event_loop.py:646 → _handle_tool_execution
strands/event_loop/event_loop.py:318 → recurse_event_loop
strands/event_loop/event_loop.py:198 → event_loop_cycle (model invocation)
→ botocore eventstream → urllib3 ReadTimeoutError
urllib3.exceptions.ReadTimeoutError: AWSHTTPSConnectionPool(host='bedrock-runtime.us-east-1.amazonaws.com', port=443): Read timed out.
Proposed Solution
Expose a model_read_timeout (or full boto_client_config) parameter in one or more of:
harness.json configuration file
InvokeHarness API / agentcore invoke CLI
- Environment variable (e.g.,
BEDROCK_READ_TIMEOUT_SECONDS)
Workaround (requires ditching Harness)
Deploy as a regular Strands agent on AgentCore Runtime and pass boto_client_config directly:
from botocore.config import Config as BotocoreConfig
from strands.models import BedrockModel
model = BedrockModel(
model_id="us.anthropic.claude-sonnet-4-5-20250929-v1:0",
boto_client_config=BotocoreConfig(read_timeout=300)
)
This defeats the purpose of the managed Harness experience.
Environment
- Account: 023392223961
- Region: us-east-1
- Runtime:
harness_team_security_reviewer-Lpq9zN5Ve7
- Log Group:
/aws/bedrock-agentcore/runtimes/harness_team_security_reviewer-Lpq9zN5Ve7-DEFAULT
- Trace ID:
6a0c0285679e59e00d1010a7ee2a910e
- Strands SDK version: bundled with Harness runtime (OTel SDK 1.40.0, auto-instrumentation 0.17.0-aws)
Problem
The AgentCore Harness runtime internally constructs a
BedrockModel(Strands SDK) without exposing theboto_client_configparameter to customers. The defaultread_timeoutof 120 seconds is insufficient for agents with complex tool chains where accumulated context causes time-to-first-token (TTFT) to exceed 120s.Impact
global.anthropic.claude-sonnet-4-5-20250929-v1:0Root Cause
From
strands/models/bedrock.py:The Harness constructs
BedrockModelwithout customer-controlledboto_client_config, so there's no way to increaseread_timeout.Stack Trace (from CloudWatch)
Proposed Solution
Expose a
model_read_timeout(or fullboto_client_config) parameter in one or more of:harness.jsonconfiguration fileInvokeHarnessAPI /agentcore invokeCLIBEDROCK_READ_TIMEOUT_SECONDS)Workaround (requires ditching Harness)
Deploy as a regular Strands agent on AgentCore Runtime and pass
boto_client_configdirectly:This defeats the purpose of the managed Harness experience.
Environment
harness_team_security_reviewer-Lpq9zN5Ve7/aws/bedrock-agentcore/runtimes/harness_team_security_reviewer-Lpq9zN5Ve7-DEFAULT6a0c0285679e59e00d1010a7ee2a910e