This is the final version of my 4-part blog series on using the AWS service Bedrock AgentCore. In this post, I’ll share a high-level overview of what AgentCore is, what we’re trying to accomplish, and how we can unlock its full potential.
If you’re seeing this for the first time, I’ve detailed the development journey in the earlier three posts—you can quickly refer to them if you’d like more depth or clarifications:
Reference to Github : https://github.com/hvmathan/bedrock-travel-agent
That said, you can still follow along with just this post—it’s self-contained and focuses on production deployment with real APIs.
Why Bedrock AgentCore Matters
In this series, I’ve been building an AI travel agent. Now, creating a travel agent chatbot isn’t new, there are plenty of ways to do it. The real difference here is how we deploy it.
We start by developing and testing locally in Python, but once the logic is solid, instead of following the traditional cloud setup,ECS/EKS cluster provisioning, load balancer configuration, auto-scaling, IAM role/policy management, CloudWatch setup, and ALB rules—we bypass all of that.
With AgentCore, all of these happen behind the scenes, automatically. The deployment itself took me less than a minute, which is mind-blowing compared to the days of setup we usually spend on infrastructure.
The Framework Question
Apart from Bedrock AgentCore, the next key choice was the framework. Since I’m working with a multi-agent system, I chose Strands Agent.
But wait, what’s a framework, and why does it matter?
Think of building an AI system like constructing a house:
- The AWS cloud (AgentCore) is the land and utilities (electricity, water, internet).
- The framework is the architecture + scaffolding, it gives you ready-made walls, wiring, and plumbing so you don’t have to reinvent everything.
- You can always build with raw bricks and cement (custom implementation), but that means drawing up blueprints, laying pipes, and wiring everything from scratch. It’s possible, but slow.
Strands Agent was like a pre-built house plan already designed for AgentCore land it fit perfectly. No hacks, no duct tape, no “custom adapters.” Just code the agent logic and deploy.
That’s why Strands became my framework of choice, it aligned directly with AWS Bedrock, unlike general-purpose frameworks such as LangChain or CrewAI, which are more powerful in some ways but require lots of integration work for AgentCore.
File Structure Breakdown
Let me walk through the final project structure and what each file accomplishes. These files are available in GitHub link that I've shared above.
AgentCore Production Files:
-
app.py- Main AgentCore wrapper with CORS support -
orchestrator.py- Core coordination logic (unchanged from local) -
planning_agent.py- Enhanced with regex parsing for flight requests -
travel_tool.py- Updated with RealFlightAPI integration -
flight_api.py- Aviationstack API integration with fallback system -
agentcore.yaml- AgentCore deployment configuration -
requirements.txt- Dependencies for cloud deployment
Local Development/Testing Files:
-
mock_travel_api.py- Original mock data for development -
booking_tools.py- Early booking agent prototype -
planning_tools.py- Standalone planning utilities -
run_agent.py- Local testing script -
my_agent.py- Initial agent prototype -
orchestrator copy.py- Backup of original orchestrator
UI and Configuration:
-
travel_ui.html- React-based professional interface -
Dockerfile- Auto-generated by AgentCore -
.env- API keys (not in repo) -
venv/- Python virtual environment
Deployment: Success and Challenges
I first developed and tested the application locally, and it worked exactly as I envisioned. For this, I integrated a third-party API that provides 100 free calls per month—more than enough for our demo purposes (covered in detail in Part 2 of this series).
Now that we’ve thoroughly tested the application in our local environment, it’s finally time to promote it to AWS.
This is where the real magic and power of AgentCore shines through. Remember the contrast I mentioned earlier—traditional deployments require hours (sometimes days) of configuring ECS/EKS clusters, IAM roles, load balancers, scaling policies, and monitoring.
With AgentCore, all of that complexity disappears. What normally takes days can now be done in just a few minutes with a single command.
In the screenshots below, you’ll see how effortlessly the application was configured and launched to AWS using AgentCore—no manual setup, no YAML headaches, just a seamless push from local code to a production-ready environment.
Deploying to AWS Bedrock AgentCore was remarkably smooth:
agentcore configure -e app.py --region us-west-2
agentcore launch
Within minutes, I had:
- ARM64 container built in AWS CodeBuild
- ECR repository created and populated
- IAM roles automatically configured
- Production endpoint deployed and ready
We can now see our application up and running on AWS.
I further have the ability the test the same from local usine the below command. The deployed agent works perfectly via CLI:
agentcore invoke '{"message": "Find flights from LHR to CDG"}'
UI Development: Building a Professional Interface
So far, we’ve explored one of the most powerful components of Bedrock AgentCore—the Runtime. To take things a step further, I wanted to give the project a more realistic touch with a proper user interface. After all, what’s an AI booking agent without an engaging front end?
I decided to build a React-based interface that showcases both local and cloud capabilities. It’s packaged as a simple HTML file, but it includes all the core functionalities I envisioned for an AI-powered booking experience as you can see in the below screenshot.
Key Features:
- Endpoint switching between local development and cloud deployment
- Real-time chat interface with typing indicators
- Quick action buttons for common requests
- Professional gradient design with AWS branding
- Mobile-responsive layout
The UI reveals an interesting architectural decision: while the local mode works seamlessly with HTTP calls, the cloud mode requires AWS SDK integration for proper authentication, making direct browser-to-AgentCore communication complex.
I performed a flight search and it gave me the perfect result as below.
How AgentCore Simplified My AWS Deployment Experience
One of the finest use cases of AgentCore I personally found impressive was how effortlessly we deployed a tested version into AWS production.
Instead of juggling YAML files, IAM roles, and cluster configs, AgentCore’s Runtime automated everything in one command.
What AgentCore Runtime Handled Automatically
- Container Building → ARM64 container built in AWS CodeBuild (no Docker setup needed)
- ECR Repository → Created and configured without lifting a finger
- IAM Roles → Both execution and CodeBuild roles provisioned with proper policies
- Auto-scaling → Production-ready scaling configuration applied out of the box
- Networking → VPC, security groups, and load balancing automatically wired
- Monitoring → CloudWatch logging enabled and integrated
- Deployment Pipeline → Complete CI/CD from code → container → running service
Traditional AWS Deployment Would Require
- Manual ECS/EKS cluster setup
- Load balancer configuration
- Auto-scaling group creation
- IAM policy writing & role management
- ECR repository and permission setup
- CloudWatch configuration
- VPC and security group management
- ALB rules & health check setup
⏱️ Time Comparison
-
With AgentCore →
agentcore launch→ 5 minutes total - Traditional AWS → ~2–3 days of infrastructure setup
The Efficiency Achievement
You literally go from local Python code → production-ready, auto-scaling AWS infrastructure in one command.
That’s the core value proposition of AgentCore Runtime:
✅ Abstract away infrastructure complexity
✅ Maintain enterprise-grade reliability and security
✅ Run seamlessly on the same AWS backbone powering major applications
And the best part? When your agent responds via:
agentcore invoke
AgentCore Components Assessment
Let me evaluate which AgentCore components I successfully leveraged:
✅ Successfully Implemented
Runtime
- Multi-agent system deployed to AgentCore Runtime
- Agent status: READY and fully functional
- Handles complex orchestration between planning and execution agents
Tools
- Real API integration with external services (Aviationstack)
- Multi-agent coordination and delegation
- Natural language processing for travel requests
- Robust fallback mechanisms for reliability
If you’re interested in exploring additional functionalities of Bedrock AgentCore, this project can be further extended with:
What's Next: Enhancement Roadmap
Phase 5 (Future): Complete AgentCore Integration
- Memory Service: Implement persistent user preferences and travel history
- Identity Service: Add user authentication and personalized experiences
- Gateway Service: Route all external API calls through AgentCore Gateway
- Enhanced Observability: Custom metrics, dashboards, and alerting
Advanced Features
- Proactive Monitoring: Price alerts for saved routes
- Multi-modal Input: Voice commands and image processing
- Integration Expansion: Hotels, car rentals, weather, and events
- Mobile App: Native iOS/Android applications
Lessons Learned
What I'd Do Differently
Start with AgentCore from Day 1: I spent time building local infrastructure that I later had to adapt. Starting with AgentCore patterns would have been more efficient.
Plan Authentication Early: The browser-to-cloud authentication challenge was more complex than anticipated. A backend proxy service would have simplified this.
Implement Memory from the Start: User context and preferences would significantly improve the experience.
What Exceeded Expectations
Deployment Simplicity: The
agentcore launchcommand handling infrastructure setup was remarkably seamless.Real API Integration: Once properly configured, the Aviationstack integration worked flawlessly with 500 requests/month being generous for development.
System Resilience: The multi-layered fallback system ensures users always get a response, even when external APIs fail.
https://aviationstack.com/login
Final Reflection
This project taught me that AWS Bedrock AgentCore excels at what it promises: rapidly transforming local agent prototypes into production-ready cloud services. The Runtime component is outstanding, handling deployment, scaling, and infrastructure management seamlessly.
The real learning came from understanding the ecosystem complexity beyond basic deployment. Authentication, persistent memory, and advanced observability require thoughtful architecture decisions that go beyond the initial deployment.
My Recommendation
For developers considering AgentCore:
- Start here if you want to focus on agent logic rather than infrastructure
- Plan authentication patterns early if you need browser-based access
- Leverage the ecosystem - AgentCore's value multiplies when using Memory, Identity, and Gateway services together
- Begin with CLI access and add web interfaces as a separate layer
The Bottom Line
The journey from local Python scripts to production AWS deployment took just a few weeks, validating AgentCore's promise of accelerated agent development and deployment.
This concludes my 4-part series on building an AI travel agent with AWS Bedrock AgentCore. The complete code and deployment configurations are available in my repository, and I'm excited to see what the community builds with these patterns.
Series Links:
- Part 1: Foundation and Architecture
- Part 2: Multi-Agent System Design
- Part 3: AgentCore Migration
- Part 4: Production Deployment and Lessons Learned (This Post)
- Aviation stack account creation - https://aviationstack.com/
Thank you,
Harsha
Top comments (1)
I'm curious about the observability aspect of your system.
Did you implement Amazon Bedrock AgentCore Observability to monitor and analyze agent interactions?
If so, how did it enhance your ability to troubleshoot and optimize the agent's performance?