CrewAI Vacation Planner on Amazon Bedrock AgentCore

An end-to-end agentic AI vacation-planning application built with CrewAI and Amazon Bedrock, containerized with Docker, deployed to Amazon Bedrock AgentCore Runtime, and exposed through AWS Lambda, Amazon API Gateway, and a Streamlit user interface.

This repository is organized into three implementation parts:

1. Part 1 — Run the CrewAI Vacation Planner locally
2. Part 2 — Containerize and deploy the CrewAI application to Amazon Bedrock AgentCore Runtime
3. Part 3 — Integrate AgentCore Runtime with Lambda, API Gateway, and Streamlit

Important: Cloning this repository gives you the application source code. It does not give you the original developer's AWS resources, AWS credentials, API keys, ECR repository, AgentCore Runtime, Lambda function, or API Gateway. You must create and configure those resources in your own AWS account.

---

Architecture

Part 1 — Local CrewAI execution

User / Terminal
      |
      v
CrewAI Vacation Planner
      |
      +--> Vacation Researcher Agent
      |        |
      |        +--> Serper Web Search
      |
      +--> Itinerary Planner Agent
               |
               v
        Amazon Bedrock
        Amazon Nova Pro
               |
               v
        Final Vacation Plan

Parts 2 and 3 — Deployed application

User
 |
 v
Streamlit UI
(running locally)
 |
 | HTTP POST
 v
Amazon API Gateway
 |
 v
AWS Lambda
 |
 | InvokeAgentRuntime
 v
Amazon Bedrock AgentCore Runtime Endpoint
 |
 v
Docker Container
 |
 v
BedrockAgentCoreApp
 |
 v
CrewAI Vacation Planner
 |
 +--> Vacation Researcher Agent --> Serper Web Search
 |
 +--> Itinerary Planner Agent --> Amazon Bedrock / Nova Pro
 |
 v
Final CrewAI Result
 |
 v
AgentCore Runtime
 |
 v
Lambda
 |
 v
API Gateway
 |
 v
Streamlit UI
 |
 v
User

---

What git clone Gives You

After cloning this repository, you receive the tracked project source files, including the CrewAI application, configuration files, Docker configuration, dependency files, and Streamlit client.

You do not receive cloud resources or secrets.

| Included in the repository | You must create/configure yourself | |---|---| | CrewAI source code | AWS account | | agents.yaml and tasks.yaml | AWS credentials | | crew.py and main.py | Serper API key | | Dockerfile | Amazon ECR repository | | .dockerignore | ECR container image | | requirements.txt / pyproject.toml | AgentCore Runtime | | streamlit_api.py | AgentCore Runtime endpoint | | .gitignore | AgentCore execution role/permissions | | Project documentation | Lambda function | | | Lambda execution role/permissions | | | API Gateway REST API | | | Your API Gateway invoke URL |

Never copy another user's AWS credentials or API keys. Each deployment should use credentials and resources belonging to the AWS account in which it is deployed.

---

Project Structure

A typical cloned project looks like this:

crewai-agentcore-vacation-planner/
|
├── src/
│   └── vacation_planner/
│       ├── __init__.py
│       ├── main.py
│       ├── crew.py
│       ├── config/
│       │   ├── agents.yaml
│       │   └── tasks.yaml
│       └── tools/
|
├── knowledge/
│   └── user_preference.txt
|
├── Dockerfile
├── .dockerignore
├── .gitignore
├── requirements.txt
├── pyproject.toml
├── streamlit_api.py
├── report.md
└── README.md

Important files

| File | Purpose | |---|---| | src/vacation_planner/crew.py | Defines the CrewAI agents, tasks, LLM, tools, Crew workflow, and AgentCore Runtime entrypoint | | src/vacation_planner/main.py | Local CLI entry point for running/testing the CrewAI workflow | | config/agents.yaml | Defines the Vacation Researcher and Itinerary Planner agents | | config/tasks.yaml | Defines the research and reporting tasks | | knowledge/user_preference.txt | Example user-preference knowledge used by the project | | pyproject.toml | Python project metadata, dependencies, and CrewAI scripts | | requirements.txt | Container/runtime Python dependencies | | Dockerfile | Packages the application for AgentCore Runtime | | .dockerignore | Prevents local-only files from entering the Docker build context | | .gitignore | Prevents secrets, virtual environments, caches, and local files from being committed | | streamlit_api.py | Local Streamlit frontend that calls the deployed API Gateway endpoint |

---

Prerequisites

Install or configure the following before starting:

• Git
• Python 3.11
• uv
• Docker Desktop
• AWS CLI v2
• An AWS account
• AWS credentials with permissions appropriate for the resources you create
• Amazon Bedrock model access for the model used by the project
• Serper API key
• Access to create ECR, AgentCore, IAM, Lambda, API Gateway, and CloudWatch resources

The examples in this project use AWS Region:

us-west-2

Keep the related AWS resources in the same region unless you intentionally redesign the deployment.

---

Local Development vs AgentCore Runtime Deployment

One of the most important design choices in this project is that local development and container deployment use the same CrewAI application code, but they prepare and install that application differently.

Understanding this distinction makes the project easier to reproduce.

What changes when moving from local CrewAI to AgentCore Runtime?

The original CrewAI application can run directly on a developer's laptop. To make the same application deployable to Amazon Bedrock AgentCore Runtime, several deployment-specific additions are required.

| Area | Local CrewAI | AgentCore Runtime deployment | |---|---|---| | Python environment | Local .venv | Python environment inside Docker image | | Dependency workflow | uv + pyproject.toml + uv.lock | pip + requirements.txt inside Docker | | Application entry | CrewAI local command / main.py | AgentCore entrypoint in crew.py | | Runtime wrapper | Not required | BedrockAgentCoreApp() | | Invocation decorator | Not required | @app.entrypoint | | HTTP server | Not required for normal local CrewAI run | app.run(port=8080) | | Container | Not required | Dockerfile | | Build exclusions | Not required for local Python execution | .dockerignore | | Image registry | Not required | Amazon ECR | | Hosting | Developer laptop | Amazon Bedrock AgentCore Runtime |

The core CrewAI concepts do not change. The project still uses the same agents, tasks, YAML configuration, tools, and crew.kickoff() workflow.

The AgentCore changes create a deployment layer around the existing CrewAI application.

ORIGINAL LOCAL APPLICATION

pyproject.toml
      |
      v
uv sync
      |
      v
.venv
      |
      v
CrewAI
├── agents.yaml
├── tasks.yaml
├── crew.py
└── main.py


AGENTCORE-READY APPLICATION

Same CrewAI application
      |
      +--> AgentCore SDK dependency
      |
      +--> BedrockAgentCoreApp()
      |
      +--> @app.entrypoint
      |
      +--> app.run(port=8080)
      |
      +--> requirements.txt
      |
      +--> Dockerfile
      |
      +--> .dockerignore
      |
      v
Docker Image
      |
      v
Amazon ECR
      |
      v
Amazon Bedrock AgentCore Runtime

---

Files added or changed for AgentCore Runtime

1. crew.py — modified

crew.py already contained the CrewAI agents, tasks, tools, LLM configuration, and Crew definition.

For AgentCore Runtime, it was extended rather than replaced.

The important AgentCore additions are:

from bedrock_agentcore.runtime import BedrockAgentCoreApp

app = BedrockAgentCoreApp()

The runtime entrypoint was added:

@app.entrypoint
def agent_invocation(payload, context):
    destination = payload.get("topic", "Tokyo, Japan")

    vacation_crew = VacationPlanner().crew()

    result = vacation_crew.kickoff(
        inputs={
            "topic": destination
        }
    )

    return {
        "result": result.raw
    }

And the AgentCore-compatible server is started with:

if __name__ == "__main__":
    app.run(port=8080)

These additions create the bridge:

AgentCore invocation
        |
        v
@app.entrypoint
        |
        v
Extract "topic"
        |
        v
Existing CrewAI crew
        |
        v
crew.kickoff()
        |
        v
Final CrewAI result
        |
        v
JSON-compatible response

The CrewAI agents and tasks remain responsible for the agentic workflow. AgentCore Runtime is responsible for hosting and invoking the containerized application.

---

2. requirements.txt — added for the Docker build

Local development uses uv, pyproject.toml, and uv.lock.

The Docker deployment uses requirements.txt because the Dockerfile installs the runtime dependencies with:

RUN pip install --no-cache-dir -r requirements.txt

Therefore requirements.txt contains the packages that must exist inside the container for the deployed application to run.

It should include the runtime dependencies required by the application, such as CrewAI, AgentCore Runtime SDK, boto3, and other packages used by the source code.

The important distinction is:

LOCAL LAPTOP
pyproject.toml + uv.lock
        |
        v
      uv sync
        |
        v
      .venv


DOCKER BUILD
requirements.txt
        |
        v
pip install -r requirements.txt
        |
        v
Python packages installed
inside Docker image

The two workflows install dependencies for two different environments.

---

3. Dockerfile — added

The Dockerfile creates the portable runtime environment that AgentCore executes.

The project uses:

FROM python:3.11-slim

WORKDIR /app

COPY requirements.txt .

RUN pip install --no-cache-dir -r requirements.txt

COPY . .

EXPOSE 8080

ENV PYTHONPATH=/app/src

CMD ["python", "src/vacation_planner/crew.py"]

The sequence is important:

Python 3.11 base image
        |
        v
Create /app working directory
        |
        v
Copy requirements.txt
        |
        v
pip installs dependencies
        |
        v
Copy application source
        |
        v
Expose port 8080
        |
        v
Set PYTHONPATH
        |
        v
Run crew.py
        |
        v
BedrockAgentCoreApp starts

The Docker image therefore contains its own Python runtime and dependencies. It does not use the .venv from the developer's Mac.

---

4. .dockerignore — added

.dockerignore controls what Docker sends into the image build context.

Local development files and secrets should not be packaged into the container.

Typical exclusions include:

.env
.venv/
.git/
__pycache__/
*.pyc
.DS_Store

.gitignore and .dockerignore have different jobs:

| File | Purpose | |---|---| | .gitignore | Prevents selected files from being tracked and pushed to GitHub | | .dockerignore | Prevents selected files from being included in the Docker build context |

A file can therefore be excluded from both Git and Docker for different reasons.

---

Why Local Development Uses uv

This project uses uv for the local Python development environment.

The important files/components are:

pyproject.toml
      |
      | defines project + dependencies
      v
uv sync
      |
      | resolves/installs dependencies
      v
uv.lock
      |
      | records resolved dependency versions
      v
.venv/
      |
      | contains the installed local Python environment
      v
CrewAI runs locally

pyproject.toml

pyproject.toml describes the Python project.

It contains information such as:

• project name,
• supported Python version,
• application dependencies,
• command-line scripts,
• build configuration.

For example:

[project]
name = "vacation_planner"
requires-python = ">=3.10,<3.13"

dependencies = [
    "bedrock-agentcore>=1.21.0",
    "boto3>=1.38.7",
    "crewai[tools]>=0.114.0,<1.0.0",
    "streamlit>=1.50.0",
]

Instead of manually installing every package one at a time, uv reads the project configuration and prepares the environment.

---

.venv

Create the local virtual environment with:

uv venv --python 3.11

This creates:

.venv/

The virtual environment isolates this project's Python interpreter and packages from other Python projects installed on the laptop.

Activate it on macOS/Linux:

source .venv/bin/activate

.venv/ is a local development artifact and should not be committed to GitHub or copied into the Docker image.

---

uv sync

Run:

uv sync

uv sync reads the project configuration and lock information and synchronizes the local .venv so that the required project packages are installed.

Conceptually:

pyproject.toml
      +
   uv.lock
      |
      v
   uv sync
      |
      v
   .venv/
      |
      +--> CrewAI
      +--> boto3
      +--> AgentCore SDK
      +--> Streamlit
      +--> other dependencies

If the local project package needs to be reinstalled:

uv sync --reinstall-package vacation-planner

---

uv.lock

uv.lock records the resolved dependency set used by the local project.

This helps make development environments reproducible.

A new learner who clones the repository can run:

uv venv --python 3.11
source .venv/bin/activate
uv sync

and uv uses the project metadata/lock information to recreate the local development environment.

---

Why Docker Uses pip and requirements.txt

The Docker container is a separate environment from the developer's .venv.

The local .venv is not copied into AgentCore Runtime.

Instead, Docker starts with a clean Python image:

FROM python:3.11-slim

and creates the deployed environment from scratch.

The Dockerfile then executes:

COPY requirements.txt .

RUN pip install --no-cache-dir -r requirements.txt

This installs the required packages inside the Docker image.

Therefore:

LOCAL DEVELOPMENT

Mac
 |
 +--> pyproject.toml
 +--> uv.lock
 |
 v
uv sync
 |
 v
.venv
 |
 v
Run CrewAI locally


DEPLOYMENT

Docker build
 |
 +--> requirements.txt
 |
 v
pip install
 |
 v
Dependencies installed inside image
 |
 +--> application source
 |
 v
Docker image
 |
 v
ECR
 |
 v
AgentCore Runtime

uv and pip are not competing with each other here. They are being used at different stages:

• uv manages the local development environment.
• pip + requirements.txt installs dependencies into the Docker image used for AgentCore Runtime.

This keeps the local developer workflow convenient while keeping the container build explicit and easy to reproduce.

---

Part 1 to Part 2 — Exact Transition Checklist

Before Part 2, the application already runs locally with CrewAI.

To make it AgentCore-ready:

[1] Existing CrewAI application works locally
        |
        v
[2] Add bedrock-agentcore dependency
        |
        v
[3] Modify crew.py
        |
        +--> import BedrockAgentCoreApp
        +--> app = BedrockAgentCoreApp()
        +--> @app.entrypoint
        +--> map payload["topic"] to crew.kickoff()
        +--> return result.raw
        +--> app.run(port=8080)
        |
        v
[4] Add requirements.txt
        |
        v
[5] Add Dockerfile
        |
        v
[6] Add .dockerignore
        |
        v
[7] Build Docker image
        |
        v
[8] Test /ping and /invocations locally
        |
        v
[9] Create ECR repository
        |
        v
[10] Push image to ECR
        |
        v
[11] Create/configure AgentCore Runtime execution role
        |
        v
[12] Create AgentCore Runtime from ECR image
        |
        v
[13] Create/test Runtime endpoint

This is the key transition in the project:

CrewAI is the agentic application. Docker packages it. ECR stores the image. AgentCore Runtime hosts and invokes the containerized application.

---

Part 1 — Clone and Run the CrewAI Application Locally

Step 1 — Clone the GitHub repository

git clone https://github.com/safiahasan29/crewai-agentcore-vacation-planner.git

Move into the project:

cd crewai-agentcore-vacation-planner

Check the files:

ls

---

Step 2 — Create a Python 3.11 virtual environment

Using uv:

uv venv --python 3.11

Activate it on macOS/Linux:

source .venv/bin/activate

If uv is not installed:

pip install uv

---

Step 3 — Install project dependencies

Synchronize the environment from the project configuration:

uv sync

If the local package needs to be reinstalled:

uv sync --reinstall-package vacation-planner

---

Step 4 — Create your local .env

Create the file in the project root:

touch .env

Add your own Serper API key:

SERPER_API_KEY=YOUR_SERPER_API_KEY

Do not commit .env.

The repository's .gitignore should exclude local-only files such as:

.env
.venv/
__pycache__/
*.pyc
.DS_Store

Verify before committing anything:

git status

Your .env should not appear as a tracked/staged file.

---

Step 5 — Configure AWS credentials

The CrewAI application uses Amazon Bedrock. Configure AWS authentication using the AWS CLI or another supported AWS credential provider.

For a local development profile:

aws configure

Enter credentials belonging to your own AWS account and choose the appropriate region, for example:

Default region name: us-west-2

Verify authentication:

aws sts get-caller-identity

Never hard-code AWS access keys or secret access keys into Python source files.

---

Step 6 — Understand the local CrewAI workflow

The project uses two agents.

Vacation Researcher

The research agent gathers information about the requested destination and can use the Serper web-search tool.

Itinerary Planner

The itinerary agent uses the research output to create the final vacation plan.

The Crew runs sequentially:

User destination
      |
      v
Vacation Researcher
      |
      v
Research Task
      |
      v
Itinerary Planner
      |
      v
Reporting Task
      |
      v
Final Vacation Plan

The task input is passed using the topic variable:

VacationPlanner().crew().kickoff(
    inputs={
        "topic": destination
    }
)

The same topic contract is preserved when the application is later deployed to AgentCore Runtime.

---

Step 7 — Run CrewAI locally

From the project root:

uv run crewai run

The application loads:

• crew.py
• agents.yaml
• tasks.yaml
• the configured Amazon Bedrock LLM
• Serper web search

The agents then execute their tasks sequentially.

A successful run generates the vacation-planning output and can write the final report to:

report.md

At this point, the CrewAI application is working locally. AWS AgentCore Runtime is not yet involved.

---

Part 2 — Containerize and Deploy to Amazon Bedrock AgentCore Runtime

What changes in Part 2?

Part 1 executes the CrewAI workflow directly on the local machine.

Part 2 makes that same application callable through Amazon Bedrock AgentCore Runtime.

The core idea is:

Existing CrewAI Application
          |
          + AgentCore Runtime SDK
          |
          + @app.entrypoint
          |
          + app.run(port=8080)
          |
          v
Docker Container
          |
          v
Amazon ECR
          |
          v
AgentCore Runtime

---

Step 1 — Add the AgentCore Runtime dependency

The project requires the AgentCore Runtime SDK.

The dependency is included in the project configuration/requirements, for example:

bedrock-agentcore

Install/synchronize dependencies after changing the project configuration:

uv sync

---

Step 2 — Wrap the CrewAI application with BedrockAgentCoreApp

In src/vacation_planner/crew.py, import the AgentCore Runtime application wrapper:

from bedrock_agentcore.runtime import BedrockAgentCoreApp

Create the application:

app = BedrockAgentCoreApp()

This does not replace CrewAI. CrewAI still performs the agent orchestration.

BedrockAgentCoreApp provides the runtime-facing application interface used to host the CrewAI workflow in AgentCore Runtime.

---

Step 3 — Add the AgentCore entrypoint

The runtime needs a function that receives invocation payloads.

@app.entrypoint
def agent_invocation(payload, context):
    destination = payload.get("topic", "Tokyo, Japan")

    vacation_crew = VacationPlanner().crew()

    result = vacation_crew.kickoff(
        inputs={
            "topic": destination
        }
    )

    return {
        "result": result.raw
    }

Request:

{
  "topic": "Plan a 3-day vacation to San Diego"
}

The entrypoint:

1. receives the AgentCore invocation,
2. extracts topic,
3. creates the CrewAI crew,
4. calls crew.kickoff(),
5. returns the final CrewAI text in a JSON-compatible dictionary.

---

Step 4 — Start the AgentCore-compatible server

At the bottom of crew.py:

if __name__ == "__main__":
    app.run(port=8080)

The containerized application listens on port 8080.

During local container testing, the application supports runtime endpoints such as:

GET  /ping
POST /invocations

---

Step 5 — Create the Dockerfile

The project Dockerfile packages the CrewAI application and AgentCore Runtime integration.

FROM python:3.11-slim

WORKDIR /app

COPY requirements.txt .

RUN pip install --no-cache-dir -r requirements.txt

COPY . .

EXPOSE 8080

ENV PYTHONPATH=/app/src

CMD ["python", "src/vacation_planner/crew.py"]

The .dockerignore should prevent unnecessary or sensitive local files from being copied into the Docker build context.

Example:

.env
.venv
.git
__pycache__
*.pyc
.DS_Store

---

Step 6 — Build the Docker image

From the project root:

docker build -t vacation-planner-agentcore .

Confirm the image exists:

docker images

---

Step 7 — Test the container locally

Run the container.

If the application requires AWS credentials and a Serper key during local testing, provide them securely using your own local configuration/environment. Do not bake secrets into the image.

Once running, test health:

curl http://localhost:8080/ping

A healthy runtime should return a health response.

Test an invocation:

curl -X POST http://localhost:8080/invocations \
  -H "Content-Type: application/json" \
  -d '{"topic":"Paris"}'

A successful response should contain the CrewAI result.

Stop/remove the local test container when finished.

---

Step 8 — Create your own Amazon ECR repository

In your AWS account, create a private ECR repository, for example:

vacation-planner-agentcore

Use the same AWS region as the AgentCore deployment, for example:

us-west-2

Do not expect the ECR repository from the original deployment to exist in your AWS account.

---

Step 9 — Authenticate Docker to Amazon ECR

Retrieve the ECR login token and authenticate Docker.

Replace <ACCOUNT_ID> with your AWS account ID:

aws ecr get-login-password --region us-west-2 \
| docker login \
  --username AWS \
  --password-stdin <ACCOUNT_ID>.dkr.ecr.us-west-2.amazonaws.com

---

Step 10 — Tag and push the image to ECR

Use the repository URI generated by your ECR repository.

Example:

docker tag vacation-planner-agentcore:latest \
<ACCOUNT_ID>.dkr.ecr.us-west-2.amazonaws.com/vacation-planner-agentcore:latest

Push:

docker push \
<ACCOUNT_ID>.dkr.ecr.us-west-2.amazonaws.com/vacation-planner-agentcore:latest

Verify the image appears in the ECR console.

Depending on the AgentCore Runtime architecture you select/use, build the container image for the architecture required by that runtime. Do not assume an image built for the laptop's native architecture is automatically correct for the target runtime.

---

Step 11 — Create the AgentCore Runtime

In Amazon Bedrock AgentCore, create a Runtime using your ECR image.

Configure:

• Runtime name
• AWS Region
• ECR container image URI
• Execution role
• Runtime networking/configuration as required by your deployment

AgentCore Runtime runs the containerized CrewAI application.

Conceptually:

Amazon Bedrock AgentCore
          |
          v
AgentCore Runtime
          |
          v
Your Docker Container
          |
          v
BedrockAgentCoreApp
          |
          v
CrewAI

---

Step 12 — Configure the AgentCore Runtime execution role

The runtime execution role is the IAM role assumed by the running AgentCore workload.

It needs permissions for the resources the application actually uses.

For this project, that can include permissions for:

• pulling the container image from ECR,
• writing runtime logs,
• invoking the configured Amazon Bedrock model,
• AgentCore workload/runtime operations required by the service.

Use least privilege and your own account/resource ARNs.

Do not copy another AWS account ID into your IAM policies.

The model invocation portion needs permissions such as:

{
  "Effect": "Allow",
  "Action": [
    "bedrock:InvokeModel",
    "bedrock:InvokeModelWithResponseStream"
  ],
  "Resource": [
    "arn:aws:bedrock:*::foundation-model/*"
  ]
}

Adjust IAM permissions to the exact resources and AWS configuration you use.

---

Step 13 — Configure runtime secrets/environment

The application uses:

os.getenv("SERPER_API_KEY")

Therefore the deployed runtime must receive a valid Serper API key through an appropriate secret/environment configuration.

Do not put the real key in:

• crew.py,
• Dockerfile,
• requirements.txt,
• GitHub,
• container image source.

---

Step 14 — Create/test an AgentCore Runtime endpoint

Create or use a Runtime endpoint and invoke it with a payload that matches the application contract:

{
  "topic": "Plan a 3-day vacation to San Diego"
}

The runtime passes the payload to:

@app.entrypoint

which then calls:

VacationPlanner().crew().kickoff(...)

A successful response contains the final vacation plan.

At this point, the CrewAI application is deployed to AgentCore Runtime.

---

Part 3 — Lambda + API Gateway + Streamlit Integration

Part 3 exposes the deployed AgentCore application to a frontend.

Streamlit
    |
    v
API Gateway
    |
    v
Lambda
    |
    v
AgentCore Runtime Endpoint
    |
    v
CrewAI

The response travels back through the same layers in reverse.

---

Step 1 — Create an AWS Lambda function

Create a Lambda function in the same AWS region used for the AgentCore deployment.

Example configuration:

Runtime: Python
Architecture: x86_64
Region: us-west-2

Lambda acts as the bridge between API Gateway and AgentCore Runtime.

Its responsibilities are:

1. receive the API Gateway event,
2. extract the user's prompt,
3. map the prompt to the CrewAI topic input,
4. generate a runtime session ID,
5. invoke the AgentCore Runtime endpoint,
6. read the AgentCore response,
7. return an HTTP-friendly response to API Gateway.

---

Step 2 — Give Lambda permission to invoke AgentCore Runtime

The Lambda execution role must explicitly allow:

bedrock-agentcore:InvokeAgentRuntime

Scope the permission to your own AgentCore Runtime/endpoint ARN whenever possible.

Conceptual policy:

{
  "Effect": "Allow",
  "Action": "bedrock-agentcore:InvokeAgentRuntime",
  "Resource": "<YOUR_AGENTCORE_RUNTIME_OR_ENDPOINT_ARN>"
}

Without this permission, Lambda can fail with an AccessDeniedException.

---

Step 3 — Lambda invocation pattern

The Lambda function uses the AWS SDK to invoke the deployed runtime.

Conceptually:

import boto3
import json
import uuid

client = boto3.client(
    "bedrock-agentcore",
    region_name="us-west-2"
)

prompt = event.get("prompt", "")

payload = json.dumps({
    "topic": prompt
})

session_id = f"lambda_session_{uuid.uuid4().hex}"

response = client.invoke_agent_runtime(
    agentRuntimeArn="<YOUR_AGENTCORE_RUNTIME_ARN>",
    runtimeSessionId=session_id,
    payload=payload,
    qualifier="<YOUR_ENDPOINT_NAME>"
)

The key mapping is:

Frontend:
{"prompt": "Plan a 3-day vacation to San Diego"}

             |
             v

Lambda:
prompt = event.get("prompt")

             |
             v

AgentCore payload:
{"topic": prompt}

             |
             v

CrewAI:
crew.kickoff(inputs={"topic": destination})

This preserves the topic input expected by the CrewAI tasks.

---

Step 4 — Return an API-friendly Lambda response

Lambda can return a response shaped like:

return {
    "statusCode": 200,
    "headers": {
        "Content-Type": "application/json",
        "Access-Control-Allow-Origin": "*"
    },
    "body": json.dumps({
        "result": response_data,
        "session_id": session_id
    })
}

Conceptually:

CrewAI
returns final text
      |
      v
AgentCore Runtime
returns JSON-compatible result
      |
      v
Lambda
wraps it in:
statusCode + headers + body
      |
      v
API Gateway
returns HTTP response

---

Step 5 — Test Lambda in the AWS console

Create a synchronous Lambda test event.

Example:

{
  "prompt": "Plan a 3-day vacation to San Diego"
}

A successful test should return:

statusCode: 200

with the vacation plan in the response body.

---

Step 6 — Create an Amazon API Gateway REST API

Create your own REST API in the same AWS region.

Example:

API type: REST API
Endpoint type: Regional
Region: us-west-2

Create a resource such as:

/vacation-plan

Create a:

POST

method and integrate it with your Lambda function.

---

Step 7 — Deploy the API

Create a stage such as:

prod

Deploy the REST API.

API Gateway generates an invoke URL similar to:

https://<YOUR_API_ID>.execute-api.us-west-2.amazonaws.com/prod/vacation-plan

Use your own generated URL.

---

Step 8 — Test the API

You can test the POST endpoint with Postman or another HTTP client.

Request:

POST https://<YOUR_API_ID>.execute-api.us-west-2.amazonaws.com/prod/vacation-plan
Content-Type: application/json

Body:

{
  "prompt": "Plan a 3-day vacation to San Diego"
}

Confirm that the API returns an HTTP 200 response and the generated vacation plan.

---

Step 9 — Configure the Streamlit frontend

streamlit_api.py sends the user's request to API Gateway.

For a reusable public repository, do not permanently depend on another developer's API Gateway URL.

A recommended pattern is:

import os

API_URL = os.getenv("VACATION_PLANNER_API_URL")

Then configure locally:

VACATION_PLANNER_API_URL=https://<YOUR_API_ID>.execute-api.us-west-2.amazonaws.com/prod/vacation-plan

The Streamlit request is:

payload = {
    "prompt": user_input
}

response = requests.post(
    API_URL,
    json=payload,
    timeout=180
)

---

Step 10 — Run Streamlit locally

The Streamlit UI in this use case runs on the local computer; it is not deployed to EC2.

From the project root:

streamlit run streamlit_api.py

or, when using the project environment:

uv run streamlit run streamlit_api.py

Streamlit displays a local URL, commonly:

http://localhost:8501

Open it in a browser and enter a request such as:

Plan a 3-day vacation to San Diego

---

Complete Request and Response Flow

Request

1. User enters:
   "Plan a 3-day vacation to San Diego"

2. Streamlit creates:
   {"prompt": "Plan a 3-day vacation to San Diego"}

3. Streamlit POSTs the request to API Gateway.

4. API Gateway invokes Lambda.

5. Lambda extracts:
   event.get("prompt")

6. Lambda converts it to:
   {"topic": "Plan a 3-day vacation to San Diego"}

7. Lambda creates a unique runtime session ID.

8. Lambda calls:
   bedrock-agentcore:InvokeAgentRuntime

9. AgentCore Runtime routes the request to the runtime endpoint.

10. BedrockAgentCoreApp calls @app.entrypoint.

11. The entrypoint extracts "topic".

12. CrewAI executes:
    VacationPlanner().crew().kickoff(...)

13. Vacation Researcher performs the research task.

14. Itinerary Planner performs the reporting task.

15. Amazon Bedrock / Nova Pro supports the agents' LLM generation.

Response

1. CrewAI produces the final result.

2. crew.py returns:
   {"result": result.raw}

3. AgentCore Runtime returns the application response to Lambda.

4. Lambda reads the runtime response.

5. Lambda creates:
   statusCode + headers + body

6. API Gateway returns the HTTP response.

7. Streamlit parses the JSON response.

8. Streamlit extracts the final vacation-plan text.

9. The user sees the itinerary in the browser.

---

Security Checklist

Before publishing changes to GitHub:

git status

Make sure none of the following are tracked:

.env
AWS access keys
AWS secret access keys
AWS session tokens
Serper API keys
passwords
local credential files
.venv/

Never hard-code secrets in:

crew.py
main.py
streamlit_api.py
Dockerfile
README.md
agents.yaml
tasks.yaml

If a secret was ever committed to Git history, removing it from the latest file is not sufficient. Rotate/revoke that credential and clean the repository history if necessary.

---

Troubleshooting

ModuleNotFoundError: vacation_planner

Reinstall the local package:

uv sync --reinstall-package vacation-planner

---

Serper returns 403 Unauthorized

Check that:

• SERPER_API_KEY exists,
• the key is valid,
• the process/container/runtime can access the environment variable.

Do not solve this by hard-coding the key into crew.py.

---

Lambda receives AccessDeniedException for InvokeAgentRuntime

Verify that the Lambda execution role allows:

bedrock-agentcore:InvokeAgentRuntime

for the correct runtime/endpoint ARN.

The AgentCore Runtime execution role and Lambda execution role are different roles with different responsibilities.

---

Docker works locally but AgentCore deployment fails

Check:

• target container architecture,
• ECR image URI,
• AWS Region,
• AgentCore execution-role permissions,
• Bedrock model permissions,
• runtime environment variables/secrets,
• CloudWatch logs.

---

API works but Streamlit does not

Check:

• the API Gateway invoke URL,
• the /vacation-plan path,
• the deployed API stage,
• POST method,
• JSON request body,
• response parsing,
• request timeout.

---

Updating the Repository

After making changes:

git status
git add -A
git commit -m "Describe the change"
git push

Before pushing, verify that secrets are excluded.

---

Cloning the Project on Another Computer

A new learner can start with:

git clone https://github.com/safiahasan29/crewai-agentcore-vacation-planner.git

cd crewai-agentcore-vacation-planner

uv venv --python 3.11

source .venv/bin/activate

uv sync

Then the learner must:

1. create their own .env,
2. provide their own Serper API key,
3. configure their own AWS credentials,
4. verify Amazon Bedrock access,
5. run Part 1 locally,
6. create their own ECR repository,
7. build and push their own container image,
8. create their own AgentCore Runtime and endpoint,
9. configure the runtime execution role,
10. create their own Lambda function and permissions,
11. create their own API Gateway REST API,
12. configure streamlit_api.py with their own API endpoint,
13. run Streamlit locally.

---

Use Case 1 Summary

This repository demonstrates three stages of the same application:

PART 1
CrewAI Application
Running Locally

        |
        v

PART 2
CrewAI Application
Containerized with Docker
        |
        v
Amazon ECR
        |
        v
Amazon Bedrock AgentCore Runtime

        |
        v

PART 3
Local Streamlit UI
        |
        v
API Gateway
        |
        v
Lambda
        |
        v
AgentCore Runtime Endpoint
        |
        v
CrewAI + Amazon Bedrock

The result is an end-to-end example of taking a CrewAI agentic application from local development to a containerized AgentCore Runtime deployment and exposing it through a REST API to a user-facing Streamlit application.