feat(bedrock_agent): WIP - Add new Amazon Bedrock Agents Functions

[anafalcao]

Issue number:
#6300

Summary

WIP

Changes

• Bedrock Agent Functions data class
• BedrockFunctionsResponseBuilder
• BedrockAgentFunctionResolver
• Optional response fields - sessionAttributes, promptSessionAttributes, knowledgeBasesConfiguration
• Parser
• Additional validations
• name on Tool decorator
• Documentation with examples

User experience

Please share what the user experience looks like before and after this change

Checklist

If your change doesn't seem to apply, please leave them unchecked.

• Meet tenets criteria
• I have performed a self-review of this change
• Changes have been tested
• Changes are documented
• PR title follows conventional commit semantics

Is this a breaking change?

RFC issue number:

Checklist:

• Migration process documented
• Implement warnings (if it can live side by side)

Acknowledgment

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.

[codecov]

Codecov Report

Attention: Patch coverage is 97.82609% with 3 lines in your changes missing coverage. Please review.

Project coverage is 96.13%. Comparing base (ed610a4) to head (e42ceff).
Report is 12 commits behind head on develop.

Files with missing lines	Patch %	Lines
...powertools/event_handler/bedrock_agent_function.py	95.52%	2 Missing and 1 partial ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #6564      +/-   ##
===========================================
+ Coverage    96.11%   96.13%   +0.01%     
===========================================
  Files          253      255       +2     
  Lines        12086    12224     +138     
  Branches       898      909      +11     
===========================================
+ Hits         11617    11752     +135     
- Misses         369      371       +2     
- Partials       100      101       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[leandrodamascena]

Hi @anafalcao! I think we need to spend some time investigating the behavior of REPROMPT and FAILURE modes. I don't know if we can make some assumption based on the http_code response code or if we let the customer handle it. To me it makes more sense for clients to make their own choices.

[anafalcao]

Hi @leandrodamascena!
I did some tests with it, and as responseState is context-specific and not always required, I believe it’s best making responseState an optional field in BedrockFunctionResponse, rather than enforcing automatic behavior that may not align with their intent.
For example:
• User can "REPROMPT" when a parameter is present but invalid (e.g. division by zero).
• User can "FAILURE" when there’s an external error (e.g., failed call to a third-party API)

Basic example without Powertools:

    try:
        a = next((float(param['value']) for param in parameters if param['name'] == 'a'), None)
        b = next((float(param['value']) for param in parameters if param['name'] == 'b'), None)

        if a is None or b is None:
            return {
                'responseState': 'REPROMPT',
                'responseBody': {
                    'TEXT': {
                        'body': 'Both parameters "a" and "b" are required. Please provide them.'
                    }
                }
            }
            
    except ValueError:
        return {
            'responseState': 'FAILURE',
            'responseBody': {
                'TEXT': {
                    'body': 'Invalid input. Parameters "a" and "b" must be numbers.'
                }
            }
        }

[leandrodamascena]

Hi @anafalcao! Thanks a lot for looking into this. So you suggest we have a responseState field in the Response class and let the customer decide what it wants to do, right? I believe this is the right direction because the customer will have full control over the workflow and decide what reports to Bedrock.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud