DEV Community: Atul Anand

Build Production-ready AI Agents with AWS Bedrock & Agentcore

Atul Anand — Mon, 26 Jan 2026 12:31:03 +0000

So you've heard about AI agents, right? They're everywhere now… automating workflows, answering customer queries, and even planning product launches.

But here's the thing: building one that actually works in production is a whole different game compared to throwing together a ChatGPT wrapper.

I recently built an "AI-powered Product Hunt launch assistant" during the AWS AI Agent Hackathon at AWS Startup Loft, Tokyo. And honestly? It taught me a ton about what it takes to build production-ready AI agents on AWS.

In this article, I'll try to walk you through the process of how to build on AWS, think about the architecture, the tools, and share the lessons that I learnt, so you can build your own AI agent-based projects without the trial-and-error pain.

The hackathon crew at AWS AI Agent Hackathon

What We're Building: The Product Hunt Launch Assistant

Before diving into the tech, let me give you context. The Product Hunt Launch Assistant is an AI agent that helps entrepreneurs plan and execute their Product Hunt launches. It can:

Generate comprehensive launch timelines with task dependencies
Create marketing assets (taglines, tweets, descriptions)
Research successful launches in our category
Recommend hunters and outreach strategies
Remember our product context across sessions (yes, it has memory!)

The interface to prepare your project info to launch

The chat interface with real-time streaming responses

The cool part? All of this runs on AWS Bedrock using the Strands Agents SDK and AgentCore Memory. Let me break down how it all works.

If you wanna follow along or check out the code, head over to Github.

The AWS AI Agent Stack

The core components that comprise the stack are going to be:

Component	What It Does
AWS Bedrock	Managed AI service that gives us access to foundation models like Claude, Amazon Nova, Llama, etc.
Strands Agents SDK	AWS's open-source framework for building AI agents with Python
AgentCore Runtime	Serverless execution environment for our agents with session isolation
AgentCore Memory	Persistent memory system for maintaining context across sessions
AgentCore Gateway	Connects our agents to APIs, Lambda functions, and MCP servers

AI Agent Architecture

Let's look at how the Product Hunt Launch Assistant is structured:

Full system architecture

1. The Agent Layer (Strands SDK)

The heart of the application is the ProductHuntLaunchAgent class, where we create the agent.

from strands import Agent
from strands.models import BedrockModel

class ProductHuntLaunchAgent:
    def __init__(self, region_name: str = None, user_id: str = None, session_id: str = None):
        # Initialize the Bedrock model (Claude 3.5 Haiku)
        self.model = BedrockModel(
            model_id="anthropic.claude-3-5-haiku-20241022-v1:0",
            temperature=0.3,
            region_name=self.region,
            stream=True  # Enable streaming
        )

        # Create the agent with Product Hunt tools and memory hooks
        self.agent = Agent(
            model=self.model,
            tools=[
                generate_launch_timeline,
                generate_marketing_assets,
                research_top_launches,
            ],
            system_prompt=self.system_prompt,
            hooks=[self.memory_hooks],
        )

What I love about Strands is how minimal the code is. You give it:

A model (Claude via Bedrock in this case)
A list of tools the agent can use
A system prompt with domain expertise
Optional hooks for things like memory

And that's it! The framework handles all the reasoning, tool selection, and response generation. No complex prompt chains or hardcoded workflows.

2. Custom Tools with the @tool Decorator

Tools are where our agent gets its superpowers. Strands makes it dead simple with the @tool decorator:

from strands import tool

@tool
def generate_launch_timeline(
    product_name: str,
    product_type: str,
    launch_date: str,
    additional_notes: str = ""
) -> Dict[str, Any]:
    """
    Generate a comprehensive launch timeline and checklist for Product Hunt launch.

    Args:
        product_name: Name of the product to launch
        product_type: Type of product (SaaS, Mobile App, Chrome Extension, etc.)
        launch_date: Target launch date (e.g., "next Tuesday", "December 15, 2024")
        additional_notes: Any additional requirements or constraints
    """
    # Parse launch date, calculate timeline, return structured data
    parsed_date = parse_launch_date(launch_date)
    days_until_launch = calculate_timeline_days(parsed_date)

    timeline = create_timeline(product_name, product_type, parsed_date, days_until_launch)

    return {
        "success": True,
        "timeline": timeline,
        "total_days": days_until_launch,
        "launch_date": format_date_for_display(parsed_date),
        "key_milestones": extract_milestones(timeline)
    }

The docstring is super important here!!! as it tells the AI model what the tool does and when to use it. The model reads this and decides autonomously when to invoke each tool based on user queries.

AI-generated launch timeline with detailed task breakdown

3. The Memory System (AgentCore Memory)

This is where things get interesting. Most AI chatbots are stateless. They forget everything after each conversation. But for a SaaS product, we need persistence. We need the agent to remember:

What product is the user launching
Their preferences and communication style
Previous recommendations and decisions

AgentCore Memory solves this with two types of memory:

Short-term memory: Keeps track of the current conversation
Long-term memory: Stores key insights across multiple sessions

Here's how I implemented memory hooks with Strands:

from bedrock_agentcore.memory import MemoryClient
from strands.hooks import HookProvider, HookRegistry, MessageAddedEvent, AfterInvocationEvent

class ProductHuntMemoryHooks(HookProvider):
    def __init__(self, memory_id: str, client: MemoryClient, actor_id: str, session_id: str):
        self.memory_id = memory_id
        self.client = client
        self.actor_id = actor_id
        self.session_id = session_id

    def retrieve_product_context(self, event: MessageAddedEvent):
        """Retrieve product and user context BEFORE processing the query."""
        user_query = messages[-1]["content"][0]["text"]

        # Get relevant memories from both namespaces
        for context_type, namespace in self.namespaces.items():
            memories = self.client.retrieve_memories(
                memory_id=self.memory_id,
                namespace=namespace.format(actorId=self.actor_id),
                query=user_query,
                top_k=3,
            )
            # Inject context into the user's message
            # ...

    def save_launch_interaction(self, event: AfterInvocationEvent):
        """Save the interaction AFTER the agent responds."""
        self.client.create_event(
            memory_id=self.memory_id,
            actor_id=self.actor_id,
            session_id=self.session_id,
            messages=[
                (user_query, "USER"),
                (agent_response, "ASSISTANT"),
            ],
        )

The key insight here is the hook system. Before each message is processed, we retrieve relevant memories and inject them as context. After the agent responds, we save the interaction for future reference.

The agent remembering product context across sessions

I set up two memory strategies:

USER_PREFERENCE: Stores user preferences, communication style, strategic approaches, etc.
SEMANTIC: Stores factual information about products, launch strategies, recommendations, etc.

The memories expire after 90 days (configurable), and the memory ID is stored in AWS SSM Parameter Store for persistence.

Building the API Layer

For the web interface, I used FastAPI with Server-Sent Events (SSE) for streaming responses:

from fastapi import FastAPI
from fastapi.responses import StreamingResponse

app = FastAPI()

@app.post("/api/chat-stream")
async def chat_stream(request: ChatRequest):
    async def event_generator():
        agent = get_or_create_agent(request.user_id, request.session_id)

        for chunk in agent.chat_stream(request.message):
            yield f"data: {json.dumps({'content': chunk})}\n\n"

        yield "data: [DONE]\n\n"

    return StreamingResponse(event_generator(), media_type="text/event-stream")

The streaming experience is crucial for UX. Nobody wants to stare at a loading spinner for 10 seconds.

And, that's actually it!

It's that simple and straightforward.

You can simply add a UI to the backend (or vibe code it), and you've built a fully functional, scalable, and production-ready SaaS for yourself.

But, to truly make it production-ready, there are a few things that I'd do differently.

Lessons Learned: What I'd Do Differently

1. Start with AgentCore Runtime for Production

When I built this, I ran the agent locally. For production, I'd use AgentCore Runtime from day one. It gives you:

Session isolation (no state leaking between users)
8-hour execution windows (for long-running tasks)
Pay-per-use pricing
Built-in security with identity management

2. Use Infrastructure as Code

The hackathon version has no Terraform/CDK. Big mistake for production. I'd always go with IaC to keep things consistent and manageable:

Memory resources defined in CloudFormation
Lambda functions for tools (if needed)
Proper IAM roles and policies

Probably wanna check this official AWS article, which outlines building AI Agents with CloudFormation.

3. Build Modular Tools

My tools are pretty monolithic. In hindsight, I'd break them into smaller, composable pieces. For example:

parse_date tool
calculate_timeline tool
format_output tool

This makes the agent more flexible and easier to test.

4. Plan for Multi-Agent Systems

The Product Hunt assistant is a single agent. But as your SaaS grows, you'll want multiple agents working together:

A research agent that finds competitor data
A content agent that writes marketing copy
A scheduling agent that optimizes launch timing
An orchestrator agent that coordinates everything

Also, apart from these, some best practices that I'd put into place would be to:

Collect ground truth data: building a dataset of user queries and expected responses for testing
Use Bedrock Guardrails: adding safety rails to prevent harmful outputs
Monitor with AgentCore Observability: integrating with CloudWatch, Datadog, or LangSmith for clear insights and observability
Test tool selection: making sure the agent picks the right tool for each query

Alright, that's it! If you've made it this far, you now know more about building AI agents on AWS than most developers out there. The stack is still evolving fast, but the fundamentals of tools, memory, and agents aren't going anywhere.

If you wanna try it out yourself, find the code for the assistant on Github.

So go ahead, clone the repo, break things, and build something cool. And hey, if you end up launching on Product Hunt using this assistant, let me know, I'd love to see what you ship!

Save money on AWS by getting daily cost notifications for FREE!

Atul Anand — Mon, 20 Jan 2025 16:32:57 +0000

Are you a solo using an AWS account, a startup building on AWS, or a big company with multiple AWS Organizations having a multi-account setup? Do you also find it challenging to track billing and manage costs across all the accounts?

In my 5+ years of AWS journey, I have seen many organizations struggle with the complexity of tracking and managing their cloud expenses.

The Pain Point

One of the most common challenges organizations face using AWS is the lack of real-time visibility into their cloud expenses.

The critical complexity is in the early identification of outliers in case of cost spikes, or identification of unnecessary costs because of dormant resources. The lack of visibility and timely insight into daily expenses can lead to unexpected bills and budget overruns, causing significant stress and financial strain.

Although we do have the provisions of Budget Alerts, it’s hard to predict daily cost initially and the range varies quite a lot based on usage. Moreover, it’s such a daunting and time-consuming task to keep monitoring daily costs using AWS Cost Explorer daily.

Wouldn’t it be nice to get a simple notification that tells you daily cost by services and by accounts, and save the hassle of jumping across AWS accounts billing dashboards?

So for this, I bring you a serverless solution called ‘AWS Cost Report’!

The Solution: AWS Cost Report

The AWS Cost Report is an open-source project that addresses this challenge by automating the collection and reporting of AWS cost data.

By leveraging serverless technologies, this solution provides a seamless and efficient way to monitor daily costs and receive notifications in your preferred communication platform (Slack or Microsoft Teams).

Access it on Github: https://github.com/ibatulanandjp/aws-cost-report

Key Features

Automated Cost Data Collection: The solution fetches daily cost data from AWS Cost Explorer, eliminating the need for manual data retrieval.
Daily Notifications: Receive daily cost reports in Slack or Microsoft Teams, providing timely insights into your cloud expenses.
Multi-Account Support: The solution can be deployed in a master account to aggregate costs from multiple child accounts, providing a consolidated view of expenses.
Customizable Configuration: Easily configure the solution to suit your needs, including account IDs, preferred currency, timezone offset, and notification platform.

Technical Architecture

The AWS Cost Report project is built using AWS Lambda and AWS CDK, ensuring a scalable and cost-effective solution. Let’s dive into the technical architecture of the system.

Architecture Overview

Multi-Account

This deployment architecture can be used where you have one or multiple departments or organizational units managing their own AWS Organization, then you can deploy it at the Master Account level. The system will aggregate the account-wise cost and send notifications to the subscribed channel.

Standalone Account

This setup is useful to deploy to a single account and get notifications daily in the subscribed channel specific to that account only.

Components

AWS Lambda Function

The core functionality of the application is implemented within an AWS Lambda function. This function performs the following tasks:

Fetch Cost Data: The function uses the AWS Cost Explorer API to fetch daily cost data for the specified account(s).
Process Data: The fetched data is processed to calculate costs in the preferred currency and format the information for notification.
Send Notifications: The function constructs a notification message and sends it to the configured Slack or Microsoft Teams channel using webhook URLs.

AWS CloudWatch Events Rule

A CloudWatch Events rule is scheduled to trigger the Lambda function daily at a specific time (e.g., 8 am JST or 23:00 UTC). When triggered, the rule invokes the Lambda function to collect and process the cost data.

External Notification Platforms (Slack or Microsoft Teams)

The application sends notifications to the specified Slack or Microsoft Teams channel using webhook URLs configured in the application.

Daily Notification Output

Once configured and deployed in the AWS account(s), you’ll start receiving daily notifications for the costs incurred sorted by service.

The notification summarizes your AWS costs, helping you stay informed about your cloud expenses. Here’s an example of how the notification will look in Slack and Microsoft Teams:

Slack Notification

Microsoft Teams Notification

The notification message includes the following information:

Date: The date for which the cost data is reported.
Account: Account ID and alias name set for that account.
Total Cost: The total cost (in your preferred currency) incurred for the specified accounts on the given date.
Cost by Service: A breakdown of the expenses by AWS service, showing top services and how they contributed to the total cost.

So, just go and clone the Github Repo now 🚀: https://github.com/ibatulanandjp/aws-cost-report.git

Hope this helps manage your AWS costs and would be happy to accept contributions on the repo, to make it more robust, and allow it to cater notifications to different platforms.

If you are into AWS, I recommend your next read to be:
Switch between AWS Accounts in your CLI like never before

This article was originally published on Medium.

Switch between AWS accounts in your CLI like never before!

Atul Anand — Sat, 05 Oct 2024 13:23:43 +0000

Struggling with hopping between thousands of AWS Accounts and assuming millions of roles on your CLI? Is storing and managing credentials a headache for you? Don’t worry… I have got your back! Just follow me till the end :)

Managing programmatic access to AWS has always been troublesome. I have been in this situation quite a lot, and that forced me to look out for ways to simplify my life so that I can focus more on getting things done quicker, without the hassle of remembering Account IDs, AWS Role names, and a whole lot of other things. Phew!

Without any fancy intro, let’s get right into it.

Let me walk you through some approaches to authenticating and gaining access to AWS resources programmatically or from the AWS CLI.

Note: The following approaches expects that you already have access to SSO authentication within IAM Identity Center, for yourself to be able to use it. You should ideally have met these prerequisites.

In short, you should be able to see the following screen:

You can access this page using the SSO start URL, which usually appears like https://d-1a2bc34de5.awsapps.com/start/.

Special Tip: You can customize the SSO Start URL as well to something of your choice very easily, simply by following this.
This changes https://d-1a2bc34de5.awsapps.com/start/ → https://mysso-myway.awsapps.com/start/. This is extremely helpful, as it is often hard to remember these similar looking URLs, especially when you have multiple such SSO URLs. :)

Approach #1: Exporting Environment Variables

The very first and foremost approach, which is quite a common way is to export the temporary credentials as environment variables. This method is especially useful for temporary access, and scripting.

Steps:

[1] Obtain Temporary Credentials (Access Keys) for the account and role, from the AWS Access Portal:

[2] Export the copied credentials as environment variables, in your terminal:

export AWS_ACCESS_KEY_ID=<YourAccessKeyId>
export AWS_SECRET_ACCESS_KEY=<YourSecretAccessKey>
export AWS_SESSION_TOKEN=<YourSessionToken>

You can confirm the allowed access by running the command:

$ aws sts get-caller-identity
{
    "UserId": "ABCD1234EFGH5678IJKL9:ibatulanand+test+@gmail.com",
    "Account": "111111111111",
    "Arn": "arn:aws:sts::111111111111:assumed-role/AWSReservedSSO_personal_a12b345cde6fg789/ibatulanand+test+@gmail.com"
}

My take on this approach:
It’s easy-peasy to gain access and switching accounts only requires copying and exporting environment variables of other accounts. This is what most of the people I have heard of use because of its simplicity, and effectiveness mainly for temporary access or development purposes.
But, as I mentioned, it is effective for temporary use only. Moreover, the credentials are exposed in the environment as well, which isn’t the best.

Approach #2: Configuring AWS-provided Wizard

1. Using “aws configure sso” wizard

This solution is particularly native to AWS, as it provides profile management through the aws configure sso wizard and this method is quite user-friendly for setting up multiple profiles.

Steps:

[1] Run the configuration wizard and provide the following information:

$ aws configure sso
SSO session name (Recommended): mysso
SSO start URL [None]: https://mysso-myway.awsapps.com/start/
SSO region [None]: ap-northeast-1
SSO registration scopes [None]: sso:account:access
Attempting to automatically open the SSO authorization page in your default browser.
If the browser does not open or you wish to use a different device to authorize this request, open the following URL:

https://device.sso.ap-northeast-1.amazonaws.com/

Then enter the code:
FTXD-TLBW

...   ...

...   ...

There are 5 AWS accounts available to you.
Using the account ID 111111111111
The only role available to you is: personal
Using the role name "personal"
CLI default client Region [ap-northeast-1]:
CLI default output format [None]:
CLI profile name [personal]:

To use this profile, specify the profile name using --profile, as shown:
aws s3 ls --profile personal

You can verify the access by running:

aws sts get-caller-identity --profile personal
{
    "UserId": "ABCD1234EFGH5678IJKL9:atul-test@gmail.com",
    "Account": "111111111111",
    "Arn": "arn:aws:sts::111111111111:assumed-role/AWSReservedSSO_personal_a12b345cde6fg789/atul-test@gmail.com"
}

You can also confirm this by checking the ~/.aws/config file:

$ cat ~/.aws/config     

[default]
region = ap-northeast-1

[profile personal]
sso_session = mysso
sso_account_id = 111111111111
sso_role_name = personal
region = ap-northeast-1

My take on this approach:
It definitely is a better and sort of long-term solution, as compared to the first approach. And, it simplifies the setup process and integrates seamlessly with AWS SSO.
But, the wizard itself has limited capabilities and may require a lot of effort in case you have multiple accounts and roles. Also, you would need to create as many different profiles for each combination.

2. Using “aws configure sso-session” wizard

This is the new addition to the approaches by AWS, and as per AWS, it is not compatible with the legacy IAM Identity Center.

Following a similar procedure as the aws configure sso, you will be able to create an sso-session in the ~/.aws/config file, which will look something like this:

$ cat ~/.aws/config     

[default]
region = ap-northeast-1

[profile personal]
sso_session = mysso
sso_account_id = 111111111111
sso_role_name = personal
region = ap-northeast-1

[sso-session mysso]
sso_start_url = https://mysso-myway.awsapps.com/start/
sso_region = ap-northeast-1
sso_registration_scopes = sso:account:access

The real benefit of this method is that it allows sso-session configurations to be reused across multiple profiles, like dev, pre-prod, prod, or any profile categorization you may have.

My take on this approach:
This approach sounds most promising so far, as it offers advanced configuration options, and fine-grained control over sessions. Also, these wizard bases approaches allow to retrieve and cache a set of credentials by running these commands:
“$ aws sso login — profile personal” OR “$ aws sso login — sso-session mysso”
But, it still is complex to setup and requires additional management in the future.

Approach #3: Using the “aws-sso-cli” utility tool

Now comes the one I was waiting to tell you all about!
This approach enhances the experience with a simple, yet powerful, utility tool that provides so much convenience and flexibility. This tool is an absolute game-changer, making the whole process of switching accounts and assuming roles incredibly smooth.

I can’t emphasize enough how much aws-sso-cli has improved my workflow, especially because it offers a streamlined and intuitive interface.

Steps:

[1] Install the aws-sso-cli utility tool following the official documentation, or if you’re on Mac, you can simply install it using Homebrew using the command:

brew install aws-sso-cli

[2] Run the following command to do the basic configuration:

aws-sso

This will allow us to set permission up like this:

And, after the configuration is done, it shows:

$ aws-sso

 Verify this code in your browser: XTRD-XZBM
List of AWS roles for SSO Instance: Default [Expires in: 6h  2m]

AccountIdPad | AccountAlias        | RoleName       | Profile                     | Expires
=======================================================================================================
111111111111 | Atul Anand          | personal       | 111111111111:personal       | Expired
222222222222 | xxx-xxxxx-xxxxx     | admin          | 222222222222:admin          | Expired
333333333333 | yyy-yyyyy-yyyyy     | admin          | 333333333333:admin          | Expired
444444444444 | zzz-zzzzz-zzzzz     | developer      | 444444444444:developer      | Expired
555555555555 | test                | developer      | 555555555555:developer      | Expired

You can even enable Auto-completion using the command:

aws-sso completions -I