You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Bedrock Agents allows you to define action groups for your agents in two ways: OpenAPI schemas, and direct function integration. This issue focuses on the latter.
As a customer I can create Bedrock Agents that have tools at their disposal. These tools, or functions, can be defined as AWS Lambda functions. One Lambda function can hold one or more tools and when looked at together, they are what makes an action group.
When I build a Lambda function with multiple tools in it, I am responsible for parsing the payload sent by Bedrock and, based on certain fields, call the corresponding tool in my code (aka the tool use). The response of this tool use is then returned by my Lambda function handler according to a specific format that Bedrock expects.
This can result in some degree of boilerplate code that I have to repeat for each action group, specifically:
parsing/validating the incoming Bedrock Agent request payload
handling the event using the correct tool/function
building the response according to the response Bedrock Agent payload schema
Since the input event includes both the function and parameters fields, we can abstract most/all the boilerplate and provide a more streamlined experience.
For example, borrowing heavily from the aws-powertools/powertools-lambda-typescript#3500 we concluded a few weeks ago, we could implement a BedrockAgentFunctionResolver resolver that provides a structured way to register functions, resolve function calls, and handle requests within Lambda.
Use case
Bedrock Agents allows you to define action groups for your agents in two ways: OpenAPI schemas, and direct function integration. This issue focuses on the latter.
As a customer I can create Bedrock Agents that have tools at their disposal. These tools, or functions, can be defined as AWS Lambda functions. One Lambda function can hold one or more tools and when looked at together, they are what makes an action group.
When I build a Lambda function with multiple tools in it, I am responsible for parsing the payload sent by Bedrock and, based on certain fields, call the corresponding tool in my code (aka the tool use). The response of this tool use is then returned by my Lambda function handler according to a specific format that Bedrock expects.
This can result in some degree of boilerplate code that I have to repeat for each action group, specifically:
parsing/validating the incoming Bedrock Agent request payload
handling the event using the correct tool/function
building the response according to the response Bedrock Agent payload schema
More details aws-powertools/powertools-lambda-typescript#3710
Solution/User Experience
When paired with a Lambda function via action group, Bedrock sends and expects payloads of known shapes.
Payload Example Documentation
Payload example Documentation
Since the input event includes both the function and parameters fields, we can abstract most/all the boilerplate and provide a more streamlined experience.
For example, borrowing heavily from the aws-powertools/powertools-lambda-typescript#3500 we concluded a few weeks ago, we could implement a BedrockAgentFunctionResolver resolver that provides a structured way to register functions, resolve function calls, and handle requests within Lambda.
Alternative solutions
Acknowledgment
The text was updated successfully, but these errors were encountered: