-
Notifications
You must be signed in to change notification settings - Fork 71
AgentCore Runtime example, using new AgentCore bidirectional streaming (WebSocket) endpoint #125
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
063e305
c7a86ca
aab5661
f263986
1df8d02
ea6fb83
077e9c1
dc44be1
86aed13
188cb2b
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,3 @@ | ||
| .bedrock_agentcore.yaml | ||
| .dockerignore | ||
| .bedrock_agentcore |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,172 @@ | ||
| # Amazon Bedrock AgentCore Runtime WebSocket Example | ||
|
|
||
| This example demonstrates how to deploy a Pipecat bot to **Amazon Bedrock AgentCore Runtime** using WebSockets for communication. | ||
|
|
||
| ## Prerequisites | ||
|
|
||
| - Accounts with: | ||
| - AWS | ||
| - Deepgram | ||
| - Cartesia | ||
| - Python 3.10 or higher | ||
| - `uv` package manager | ||
|
|
||
| ## Environment Setup | ||
|
|
||
| ### IAM Configuration | ||
|
|
||
| Configure your IAM user with the necessary policies for AgentCore usage. Start with these: | ||
|
|
||
| - `BedrockAgentCoreFullAccess` | ||
| - A new policy (maybe named `BedrockAgentCoreCLI`) configured [like this](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-permissions.html#runtime-permissions-starter-toolkit) | ||
|
|
||
| You can also choose to specify more granular permissions; see [Amazon Bedrock AgentCore docs](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-permissions.html) for more information. | ||
|
|
||
| ### Environment Variable Setup | ||
|
|
||
| 1. For agent management (configuring, deploying, etc.): | ||
|
|
||
| Either export your AWS credentials and configuration as environment variables: | ||
|
|
||
| ```bash | ||
| export AWS_SECRET_ACCESS_KEY=... | ||
| export AWS_ACCESS_KEY_ID=... | ||
| export AWS_REGION=... | ||
| ``` | ||
|
|
||
| Or use AWS CLI configuration: | ||
|
|
||
| ```bash | ||
| aws configure | ||
| ``` | ||
|
|
||
| 2. For the agent itself: | ||
|
|
||
| ```bash | ||
| cd agent | ||
| cp env.example .env | ||
| ``` | ||
|
|
||
| Add your API keys: | ||
|
|
||
| - `AWS_ACCESS_KEY_ID`: Your AWS access key ID for the Amazon Bedrock LLM used by the agent | ||
| - `AWS_SECRET_ACCESS_KEY`: Your AWS secret access key for the Amazon Bedrock LLM used by the agent | ||
| - `AWS_REGION`: The AWS region for the Amazon Bedrock LLM used by the agent | ||
| - `DEEPGRAM_API_KEY`: Your Deepgram API key | ||
| - `CARTESIA_API_KEY`: Your Cartesia API key | ||
|
|
||
| 3. For the server: | ||
|
|
||
| ```bash | ||
| cd server | ||
| cp env.example .env | ||
| ``` | ||
|
|
||
| Add your AWS credentials and configuration, for generating a signed WebSocket URL in the `/start` endpoint: | ||
|
|
||
| - `AWS_ACCESS_KEY_ID` | ||
| - `AWS_SECRET_ACCESS_KEY` | ||
| - `AWS_REGION` | ||
|
|
||
| ### Virtual Environment Setup | ||
|
|
||
| Create and activate a virtual environment for managing the agent: | ||
|
|
||
| ```bash | ||
| uv sync | ||
| ``` | ||
|
|
||
| ## Agent Configuration | ||
|
|
||
| Configure your Pipecat agent as an AgentCore agent: | ||
|
|
||
| ```bash | ||
| uv run agentcore configure -e agent/agent.py | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I know that here you don’t need to change the And maybe the one to destroy ?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I thought about it. There were two competing interests. One was
But there's also the desire not to introduce unnecessary abstraction, to not obscure what the example is trying to demonstrate, which is usage of AgentCore with Pipecat. For configuration and destruction, wrapping the AgentCore CLI in a script adds very little.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. To be clear, I don't feel very strongly about this decision one way or another. Just wanted to explain my decision. If you feel strongly otherwise, happy to make the change.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. One advantage of wrapping it inside the script is that we can force the agent to use the
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We actually no longer to use the container option. At least not for this example. 🎉 Selecting all defaults works. |
||
| ``` | ||
|
|
||
| Follow the prompts to complete the configuration. It's fine to just accept all defaults. | ||
|
|
||
| ## ⚠️ Before Proceeding | ||
|
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Here's the warning I was describing in another comment. If this seems useful, we can update other AgentCore examples to follow suit after this PR. @filipi87
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yep, that makes sense. I think we should try to keep both examples as consistent as possible. |
||
|
|
||
| Just in case you've deployed multiple agents to AgentCore or deployed agents under multiple names, ensure that you have the desired agent selected as "default" in the `agentcore` tool: | ||
|
|
||
| ``` | ||
| # Check | ||
| uv run agentcore configure list | ||
| # Set | ||
| uv run agentcore configure set-default <agent-name> | ||
| ``` | ||
|
|
||
| The following steps act on `agentcore`'s default agent. | ||
|
|
||
| ## Deploying to AgentCore | ||
|
|
||
| Deploy your configured agent to Amazon Bedrock AgentCore Runtime for production hosting. | ||
|
|
||
| ```bash | ||
| ./scripts/launch.sh | ||
| ``` | ||
|
|
||
| You should see commands related to tailing logs printed to the console. Copy and save them for later use. | ||
|
|
||
| This is also the command you need to run after you've updated your agent code. | ||
|
|
||
| ## Running the Server | ||
|
|
||
| The server provides a `/start` endpoint that generates WebSocket URLs for the client to connect to the agent. | ||
|
|
||
| See [the server README](./server/README.md) for setup and run instructions. | ||
|
|
||
| ## Running the Client | ||
|
|
||
| Once the server is running, you can run the client to connect to your AgentCore-hosted agent. | ||
|
|
||
| See [the client README](./client/README.md) for setup and run instructions. | ||
|
|
||
| ## Testing Locally | ||
|
|
||
| To test agent logic locally before deploying to AgentCore Runtime, do the following. | ||
|
|
||
| First, run the agent locally: | ||
|
|
||
| ```bash | ||
| cd agent | ||
| uv run python agent.py | ||
| ``` | ||
|
|
||
| This will make the agent reachable at "ws://localhost:8080/ws". | ||
|
|
||
| Then, run the server as usual, but with the `LOCAL_AGENT=1` environment variable: | ||
|
|
||
| ```bash | ||
| LOCAL_AGENT=1 uv run python server.py | ||
| ``` | ||
|
|
||
| You can then [run your client as usual](#running-the-client). | ||
|
|
||
| ## Observation | ||
|
|
||
| Paste one of the log tailing commands you received when deploying your agent to AgentCore Runtime. It should look something like: | ||
|
|
||
| ```bash | ||
| # Replace with your actual command | ||
| aws logs tail /aws/bedrock-agentcore/runtimes/foo-0uJkkT7QHC-DEFAULT --log-stream-name-prefix "2025/11/19/[runtime-logs]" --follow | ||
| ``` | ||
|
|
||
| If you don't have that command handy, no worries. Just run: | ||
|
|
||
| ```bash | ||
| uv run agentcore status | ||
| ``` | ||
|
|
||
| ## Agent Deletion | ||
|
|
||
| Delete your agent from AgentCore: | ||
|
|
||
| ```bash | ||
| uv run agentcore destroy | ||
| ``` | ||
|
|
||
| ## Additional Resources | ||
|
|
||
| For a comprehensive guide to getting started with Amazon Bedrock AgentCore, including detailed setup instructions, see the [Amazon Bedrock AgentCore Developer Guide](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/what-is-bedrock-agentcore.html). | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have also added in the other example this:
export AWS_DEFAULT_REGION=your_default_regionShould we add it here as well ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's actually no need to export that in this example. There was some specific tool or something in the other example that didn't honor
AWS_REGION, but I can't now remember what exactly that was.