fix(bedrock): prevent runtime failure when toolConfig is undefined

[Priyanka-2725]

Pull Request: Fix AWS Bedrock Converse API toolConfig ValidationException

Description of the Change

Problem

When using any model with the AWS Bedrock provider, all agent runs that involve tool calls fail on subsequent turns with:

Error: converse API call failed: operation error Bedrock Runtime: Converse,
https response error StatusCode: 400, RequestID: fb82c3b1-af04-4405-8958-999d7a5e39c4,
ValidationException: The toolConfig field must be defined when using toolUse and toolResult content blocks.

The AWS Bedrock Converse API enforces a strict requirement: if any message in the request contains toolUse or toolResult content blocks, the request must include a toolConfig field — even when no new tools are being offered in the current turn. This is not a requirement imposed by other providers (OpenAI, Anthropic direct, etc.).

The CallEx and CallWithTools methods in the Bedrock provider did not account for this. As a result, any multi-turn conversation where a tool was previously called would fail on all follow-up turns, making it impossible to complete any agentic task with the Bedrock provider.

Solution

Added a buildMinimalToolsFromChain helper function in backend/pkg/providers/bedrock/bedrock.go that:

1. Scans the conversation chain for llms.ToolCall and llms.ToolCallResponse content parts.
2. Collects all unique tool names referenced across the chain.
3. Returns minimal llms.Tool placeholder definitions (with an empty {"type":"object","properties":{}} parameter schema) for each unique tool name.

These placeholder definitions are injected via llms.WithTools so the underlying library includes toolConfig in the Bedrock API request. Placeholder schemas are used intentionally — Bedrock only validates that toolConfig is present, not that the schemas match historical usage.

The fix is applied to both call paths that can hit this error:

• CallEx: detects tool blocks in the chain and injects minimal definitions when no tools were explicitly provided for the current turn.
• CallWithTools: falls back to reconstructed minimal definitions when an empty tools slice is passed but the chain contains tool blocks.

Closes #

---

Type of Change

• 🐛 Bug fix (non-breaking change which fixes an issue)
• 🧪 Test update

---

Areas Affected

• External Integrations (LLM/Search APIs)

---

Testing and Verification

Test Configuration

PentAGI Version: latest
Docker Version: N/A
Host OS: N/A
LLM Provider: AWS Bedrock (any model)
Enabled Features: N/A

Test Steps

1. Create a new provider with Bedrock as the provider type and any supported model.
2. Start an agent task that triggers at least one tool call (this causes toolUse/toolResult blocks to appear in the conversation history).
3. Allow the agent to continue to the next turn (previously this would immediately fail with ValidationException).
4. Observe that the conversation continues without error and the task completes successfully.

Test Results

Unit tests added in backend/pkg/providers/bedrock/bedrock_test.go — TestBuildMinimalToolsFromChain — covering all edge cases:

Scenario	Expected Result
nil chain	Returns nil (no tools injected)
Empty chain slice	Returns nil
Text-only chain (no tool blocks)	Returns nil
Chain with ToolCall	Returns 1 tool definition with correct name and placeholder schema
Chain with ToolCallResponse	Returns 1 tool definition with correct name
Same tool name in both ToolCall and ToolCallResponse	Deduplicated to 1 entry
Multiple distinct tool names across turns	All names returned
ToolCall with nil FunctionCall	Skipped safely, returns nil
Placeholder schema validation	type=object, empty properties map

All existing tests continue to pass.

---

Security Considerations

No security implications. The placeholder tool schemas sent to Bedrock contain no sensitive information — they exist solely to satisfy the AWS API's structural toolConfig requirement. No new dependencies are introduced.

---

Performance Impact

Negligible. buildMinimalToolsFromChain performs a single O(n) linear scan over the conversation chain on each call, and only injects tools when tool-related content blocks are actually present. No caching or persistent state is involved.

---

Documentation Updates

• README.md updates
• API documentation updates
• Configuration documentation updates
• GraphQL schema updates
• Other: N/A

No documentation updates required. The fix is an internal implementation detail of the Bedrock provider with no user-facing configuration changes.

---

Deployment Notes

No new environment variables, configuration changes, database migrations, or deployment steps required. The fix is a drop-in change to the Bedrock provider implementation.

---

Checklist

Code Quality

• My code follows the project's coding standards
• I have added/updated necessary documentation
• I have added tests to cover my changes
• All new and existing tests pass
• I have run go fmt and go vet (for Go code)

Security

• I have considered security implications
• Changes maintain or improve the security model
• Sensitive information has been properly handled

Compatibility

• Changes are backward compatible
• Breaking changes are clearly marked and documented
• Dependencies are properly updated

Documentation

• Comments are added for non-obvious code

---

Additional Notes

The root cause is an AWS Bedrock Converse API constraint that is not enforced by other LLM providers. The fix is fully isolated to backend/pkg/providers/bedrock/ and has no effect on any other provider (OpenAI, Anthropic, Gemini, Ollama, etc.).

Files changed:

• backend/pkg/providers/bedrock/bedrock.go — added buildMinimalToolsFromChain, updated CallEx and CallWithTools
• backend/pkg/providers/bedrock/bedrock_test.go — added TestBuildMinimalToolsFromChain with 8 sub-tests

[asdek]

hey @Priyanka-2725

thank you for the PR!