Transfer your AI brokers from proof of idea to manufacturing with Amazon Bedrock AgentCore

Constructing an AI agent that may deal with a real-life use case in manufacturing is a fancy endeavor. Though making a proof of idea demonstrates the potential, shifting to manufacturing requires addressing scalability, safety, observability, and operational issues that don’t floor in growth environments.

This publish explores how Amazon Bedrock AgentCore helps you transition your agentic purposes from experimental proof of idea to production-ready techniques. We observe the journey of a buyer help agent that evolves from a easy native prototype to a complete, enterprise-grade answer able to dealing with a number of concurrent customers whereas sustaining safety and efficiency requirements.

Amazon Bedrock AgentCore is a complete suite of providers designed that can assist you construct, deploy, and scale agentic AI purposes. In case you’re new to AgentCore, we suggest exploring our present deep-dive posts on particular person providers: AgentCore Runtime for safe agent deployment and scaling, AgentCore Gateway for enterprise device growth, AgentCore Identity for securing agentic AI at scale, AgentCore Memory for constructing context-aware brokers, AgentCore Code Interpreter for code execution, AgentCore Browser Tool for internet interplay, and AgentCore Observability for transparency in your agent conduct. This publish demonstrates how these providers work collectively in a real-world state of affairs.

The shopper help agent journey

Buyer help represents one of the vital widespread and compelling use circumstances for agentic AI. Fashionable companies deal with hundreds of buyer inquiries every day, starting from easy coverage inquiries to complicated technical troubleshooting. Conventional approaches typically fall brief: rule-based chatbots frustrate clients with inflexible responses, and human-only help groups wrestle with scalability and consistency. An clever buyer help agent must seamlessly deal with various situations: managing buyer orders and accounts, wanting up return insurance policies, looking out product catalogs, troubleshooting technical points by way of internet analysis, and remembering buyer preferences throughout a number of interactions. Most significantly, it should do all this whereas sustaining the safety and reliability requirements anticipated in enterprise environments. Take into account the everyday evolution path many organizations observe when constructing such brokers:

• The proof of idea stage – Groups begin with a easy native prototype that demonstrates core capabilities, reminiscent of a fundamental agent that may reply coverage questions and seek for merchandise. This works properly for demos however lacks the robustness wanted for actual buyer interactions.
• The fact test – As quickly as you attempt to scale past just a few check customers, challenges emerge. The agent forgets earlier conversations, instruments change into unreliable underneath load, there’s no strategy to monitor efficiency, and safety turns into a paramount concern.
• The manufacturing problem – Shifting to manufacturing requires addressing session administration, safe device sharing, observability, authentication, and constructing interfaces that clients truly need to use. Many promising proofs of idea stall at this stage because of the complexity of those necessities.

On this publish, we deal with every problem systematically. We begin with a prototype agent outfitted with three important instruments: return coverage lookup, product info search, and internet seek for troubleshooting. From there, we add the capabilities wanted for manufacturing deployment: persistent reminiscence for dialog continuity and a hyper-personalized expertise, centralized device administration for reliability and safety, full observability for monitoring and debugging, and eventually a customer-facing internet interface. This development mirrors the real-world path from proof of idea to manufacturing, demonstrating how Amazon Bedrock AgentCore providers work collectively to resolve the operational challenges that emerge as your agentic purposes mature. For simplification and demonstration functions, we think about a single-agent structure. In real-life use circumstances, buyer help brokers are sometimes created as multi-agent architectures and people situations are additionally supported by Amazon Bedrock AgentCore providers.

Answer overview

Each manufacturing system begins with a proof of idea, and our buyer help agent is not any exception. On this first section, we construct a useful prototype that demonstrates the core capabilities wanted for buyer help. On this case, we use Strands Agents, an open supply agent framework, to construct the proof of idea and Anthropic’s Claude 3.7 Sonnet on Amazon Bedrock as the massive language mannequin (LLM) powering our agent. To your utility, you need to use one other agent framework and mannequin of your selection.

Brokers depend on instruments to take actions and work together with dwell techniques. A number of instruments are utilized in buyer help brokers, however to maintain our instance easy, we concentrate on three core capabilities to deal with the commonest buyer inquiries:

• Return coverage lookup – Prospects regularly ask about return home windows, circumstances, and processes. Our device supplies structured coverage info primarily based on product classes, overlaying all the pieces from return timeframes to refund processing and delivery insurance policies.
• Product info retrieval – Technical specs, guarantee particulars, and compatibility info are important for each pre-purchase questions and troubleshooting. This device serves as a bridge to your product catalog, delivering formatted technical particulars that clients can perceive.
• Internet seek for troubleshooting – Complicated technical points typically require the most recent options or community-generated fixes not present in inside documentation. Internet search functionality permits the agent to entry the net for present troubleshooting guides and technical options in actual time.

The instruments implementation and the end-to-end code for this use case can be found in our GitHub repository. On this publish, we concentrate on the primary code that connects with Amazon Bedrock AgentCore, however you’ll be able to observe the end-to-end journey within the repository.

Create the agent

With the instruments out there, let’s create the agent. The structure for our proof of idea will appear like the next diagram.

You will discover the end-to-end code for this publish on the GitHub repository. For simplicity, we present solely the important components for our end-to-end code right here:

from strands import Agent
from strands.fashions import BedrockModel

@device
def get_return_policy(product_category: str) -> str:
    """Get return coverage info for a particular product class."""
    # Returns structured coverage information: home windows, circumstances, processes, refunds
    # test github for full code
    return {"return_window": "10 days", "circumstances": ""}
    
@device  
def get_product_info(product_type: str) -> str:
    """Get detailed technical specs and knowledge for electronics merchandise."""
    # Returns guarantee, specs, options, compatibility particulars
    # test github for full code
    return {"product": "ThinkPad X1 Carbon", "information": "ThinkPad X1 Carbon information"}
    
@device
def web_search(key phrases: str, area: str = "us-en", max_results: int = 5) -> str:
    """Search the net for up to date troubleshooting info."""
    # Supplies entry to present technical options and guides
    # test github for full code
    return "outcomes from websearch"
    
# Initialize the Bedrock mannequin
mannequin = BedrockModel(
    model_id="us.anthropic.claude-3-7-sonnet-20250219-v1:0",
    temperature=0.3
)

# Create the shopper help agent
agent = Agent(
    mannequin=mannequin,
    instruments=[
        get_product_info, 
        get_return_policy, 
        web_search
    ],
    system_prompt="""You're a useful buyer help assistant for an electronics firm.
    Use the suitable instruments to offer correct info and all the time provide extra assist."""
)

Check the proof of idea

After we check our prototype with lifelike buyer queries, the agent demonstrates the right device choice and interplay with real-world techniques:

# Return coverage inquiry
response = agent("What is the return coverage for my ThinkPad X1 Carbon?")
# Agent appropriately makes use of get_return_policy with "laptops" class

# Technical troubleshooting  
response = agent("My iPhone 14 heats up, how do I repair it?")
# Agent makes use of web_search to search out present troubleshooting options

The agent works properly for these particular person queries, appropriately mapping laptop computer inquiries to return coverage lookups and complicated technical points to internet search, offering complete and actionable responses.

The proof of idea actuality test

Our proof of idea efficiently demonstrates that an agent can deal with various buyer help situations utilizing the best mixture of instruments and reasoning. The agent runs completely in your native machine and handles queries appropriately. Nonetheless, that is the place the proof of idea hole turns into apparent. The instruments are outlined as native features in your agent code, the agent responds rapidly, and all the pieces appears production-ready. However a number of essential limitations change into obvious the second you suppose past single-user testing:

• Reminiscence loss between classes – In case you restart your pocket book or utility, the agent fully forgets earlier conversations. A buyer who was discussing a laptop computer return yesterday would want to begin from scratch right now, re-explaining their complete state of affairs. This isn’t simply inconvenient—it’s a poor buyer expertise that breaks the conversational move that makes AI brokers useful.
• Single buyer limitation – Your present agent can solely deal with one dialog at a time. If two clients attempt to use your help system concurrently, their conversations would intervene with one another, or worse, one buyer may see one other’s dialog historical past. There’s no mechanism to keep up separate dialog context for various customers.
• Instruments embedded in code – Your instruments are outlined straight within the agent code. This implies:
  • You possibly can’t reuse these instruments throughout completely different brokers (gross sales agent, technical help agent, and so forth).
  • Updating a device requires altering the agent code and redeploying all the pieces.
  • Totally different groups can’t preserve completely different instruments independently.
• No manufacturing infrastructure – The agent runs regionally as a right for scalability, safety, monitoring, and reliability.

These basic architectural boundaries can forestall actual buyer deployment. Agent constructing groups can take months to deal with these points, which delays the time to worth from their work and provides vital prices to the applying. That is the place Amazon Bedrock AgentCore providers change into important. Slightly than spending months constructing these manufacturing capabilities from scratch, Amazon Bedrock AgentCore supplies managed providers that deal with every hole systematically.

Let’s start our journey to manufacturing by fixing the reminiscence drawback first, reworking our agent from one which forgets each dialog into one which remembers clients throughout conversations and might hyper-personalize conversations utilizing Amazon Bedrock AgentCore Reminiscence.

Add persistent reminiscence for hyper-personalized brokers

The primary main limitation we recognized in our proof of idea was reminiscence loss—our agent forgot all the pieces between classes, forcing clients to repeat their context each time. This “goldfish agent” conduct breaks the conversational expertise that makes AI brokers useful within the first place.

Amazon Bedrock AgentCore Reminiscence solves this by offering managed, persistent reminiscence that operates on two complementary ranges:

• Brief-term reminiscence – Speedy dialog context and session-based info for continuity inside interactions
• Lengthy-term reminiscence – Persistent info extracted throughout a number of conversations, together with buyer preferences, info, and behavioral patterns

After including Amazon Bedrock AgentCore Reminiscence to our buyer help agent, our new structure will appear like the next diagram.

Set up dependencies

Earlier than we begin, let’s set up our dependencies: boto3, the AgentCore SDK, and the AgentCore Starter Toolkit SDK. These will assist us rapidly add Amazon Bedrock AgentCore capabilities to our agent proof of idea. See the next code:

pip set up boto3 bedrock-agentcore bedrock-agentcore-starter-toolkit

Create the reminiscence assets

Amazon Bedrock AgentCore Reminiscence makes use of configurable methods to find out what info to extract and retailer. For our buyer help use case, we use two complementary methods:

• USER_PREFERENCE – Robotically extracts and shops buyer preferences like “prefers ThinkPad laptops,” “makes use of Linux,” or “performs aggressive FPS video games.” This permits personalised suggestions throughout conversations.
• SEMANTIC – Captures factual info utilizing vector embeddings, reminiscent of “buyer has MacBook Professional order #MB-78432” or “reported overheating points throughout video enhancing.” This supplies related context for troubleshooting.

See the next code:

from bedrock_agentcore.reminiscence import MemoryClient
from bedrock_agentcore.reminiscence.constants import StrategyType

memory_client = MemoryClient(region_name=area)

methods = [
    {
        StrategyType.USER_PREFERENCE.value: {
            "name": "CustomerPreferences",
            "description": "Captures customer preferences and behavior",
            "namespaces": ["support/customer/{actorId}/preferences"],
        }
    },
    {
        StrategyType.SEMANTIC.worth: {
            "identify": "CustomerSupportSemantic", 
            "description": "Shops info from conversations",
            "namespaces": ["support/customer/{actorId}/semantic"],
        }
    },
]

# Create reminiscence useful resource with each methods
response = memory_client.create_memory_and_wait(
    identify="CustomerSupportMemory",
    description="Buyer help agent reminiscence",
    methods=methods,
    event_expiry_days=90,
)

Combine with Strands Brokers hooks

The important thing to creating reminiscence work seamlessly is automation—clients shouldn’t want to consider it, and brokers shouldn’t require guide reminiscence administration. Strands Brokers supplies a robust hook system that allows you to intercept agent lifecycle occasions and deal with reminiscence operations routinely. The hook system allows each built-in parts and person code to react to or modify agent conduct by way of strongly-typed occasion callbacks. For our use case, we create CustomerSupportMemoryHooks to retrieve the shopper context and save the help interactions:

• MessageAddedEvent hook – Triggered when clients ship messages, this hook routinely retrieves related reminiscence context and injects it into the question. The agent receives each the shopper’s query and related historic context with out guide intervention.
• AfterInvocationEvent hook – Triggered after agent responses, this hook routinely saves the interplay to reminiscence. The dialog turns into a part of the shopper’s persistent historical past instantly.

See the next code:

class CustomerSupportMemoryHooks(HookProvider):
    def retrieve_customer_context(self, occasion: MessageAddedEvent):
        """Inject buyer context earlier than processing queries"""
        user_query = occasion.agent.messages[-1]["content"][0]["text"]
        
        # Retrieve related recollections from each methods
        all_context = []
        for context_type, namespace in self.namespaces.gadgets():
            recollections = self.shopper.retrieve_memories(
                memory_id=self.memory_id,
                namespace=namespace.format(actorId=self.actor_id),
                question=user_query,
                top_k=3,
            )
            # Format and add to context
            for reminiscence in recollections:
                if reminiscence.get("content material", {}).get("textual content"):
                    all_context.append(f"[{context_type.upper()}] {reminiscence['content']['text']}")
        
        # Inject context into the person question
        if all_context:
            context_text = "n".be a part of(all_context)
            original_text = occasion.agent.messages[-1]["content"][0]["text"]
            occasion.agent.messages[-1]["content"][0]["text"] = f"Buyer Context:n{context_text}nn{original_text}"

    def save_support_interaction(self, occasion: AfterInvocationEvent):
        """Save interactions after agent responses"""
        # Get final buyer question and agent response test github for implementation
        customer_query = "It is a pattern question"
        agent_response = "LLM gave a pattern response"
        
        # Extract buyer question and agent response
        # Save to reminiscence for future retrieval
        self.shopper.create_event(
            memory_id=self.memory_id,
            actor_id=self.actor_id,
            session_id=self.session_id,
            messages=[(customer_query, "USER"), (agent_response, "ASSISTANT")]
        )

On this code, we are able to see that our hooks are those interacting with Amazon Bedrock AgentCore Reminiscence to avoid wasting and retrieve reminiscence occasions.

Combine reminiscence with the agent

Including reminiscence to our present agent requires minimal code adjustments; you’ll be able to merely instantiate the reminiscence hooks and move them to the agent constructor. The agent code then solely wants to attach with the reminiscence hooks to make use of the complete energy of Amazon Bedrock AgentCore Reminiscence. We are going to create a brand new hook for every session, which can assist us deal with completely different buyer interactions. See the next code:

# Create reminiscence hooks for this buyer session
memory_hooks = CustomerSupportMemoryHooks(
    memory_id=memory_id, 
    shopper=memory_client, 
    actor_id=customer_id, 
    session_id=session_id
)

# Create agent with reminiscence capabilities
agent = Agent(
    mannequin=mannequin,

    instruments=[get_product_info, get_return_policy, web_search],
    system_prompt=SYSTEM_PROMPT
)

Check the reminiscence in motion

Let’s see how reminiscence transforms the shopper expertise. After we invoke the agent, it makes use of the reminiscence from earlier interactions to indicate buyer pursuits in gaming headphones, ThinkPad laptops, and MacBook thermal points:

# Check personalised suggestions
response = agent("Which headphones would you suggest?")
# Agent remembers: "prefers low latency for aggressive FPS video games"
# Response contains gaming-focused suggestions

# Check choice recall
response = agent("What's my most well-liked laptop computer model?")  
# Agent remembers: "prefers ThinkPad fashions" and "wants Linux compatibility"
# Response acknowledges ThinkPad choice and suggests suitable fashions

The transformation is instantly obvious. As an alternative of generic responses, the agent now supplies personalised suggestions primarily based on the shopper’s said preferences and previous interactions. The shopper doesn’t have to re-explain their gaming wants or Linux necessities—the agent already is aware of.

Advantages of Amazon Bedrock AgentCore Reminiscence

With Amazon Bedrock AgentCore Reminiscence built-in, our agent now delivers the next advantages:

• Dialog continuity – Prospects can choose up the place they left off, even throughout completely different classes or help channels
• Personalised service – Suggestions and responses are tailor-made to particular person preferences and previous points
• Contextual troubleshooting – Entry to earlier issues and options allows more practical help
• Seamless expertise – Reminiscence operations occur routinely with out buyer or agent intervention

Nonetheless, we nonetheless have limitations to deal with. Our instruments stay embedded within the agent code, stopping reuse throughout completely different help brokers or groups. Safety and entry controls are minimal, and we nonetheless can’t deal with a number of clients concurrently in a manufacturing surroundings.

Within the subsequent part, we deal with these challenges by centralizing our instruments utilizing Amazon Bedrock AgentCore Gateway and implementing correct id administration with Amazon Bedrock AgentCore Identification, making a scalable and safe basis for our buyer help system.

Centralize instruments with Amazon Bedrock AgentCore Gateway and Amazon Bedrock AgentCore Identification

With reminiscence solved, our subsequent problem is device structure. At the moment, our instruments are embedded straight within the agent code—a sample that works for prototypes however creates vital issues at scale. Whenever you want a number of brokers (buyer help, gross sales, technical help), each duplicates the identical instruments, resulting in in depth code, inconsistent conduct, and upkeep nightmares.

Amazon Bedrock AgentCore Gateway simplifies this course of by centralizing instruments into reusable, safe endpoints that brokers can entry. Mixed with Amazon Bedrock AgentCore Identification for authentication, it creates an enterprise-grade device sharing infrastructure.

We are going to now replace our agent to make use of Amazon Bedrock AgentCore Gateway and Amazon Bedrock AgentCore Identification. The structure will appear like the next diagram.

On this case, we convert our internet search device for use within the gateway and preserve the return coverage and get product info instruments native to this agent. That’s vital as a result of internet search is a typical functionality that may be reused throughout completely different use circumstances in a company, and return coverage and manufacturing info are capabilities generally related to buyer help providers. With Amazon Bedrock AgentCore providers, you’ll be able to resolve which capabilities to make use of and mix them. On this case, we additionally use two new instruments that would have been developed by different groups: test guarantee and get buyer profile. As a result of these groups have already uncovered these instruments utilizing AWS Lambda features, we are able to use them as targets to our Amazon Bedrock AgentCore Gateway. Amazon Bedrock AgentCore Gateway can even help REST APIs as goal. That signifies that if we’ve got an OpenAPI specification or a Smithy model, we are able to additionally rapidly expose our instruments utilizing Amazon Bedrock AgentCore Gateway.

Convert present providers to MCP

Amazon Bedrock AgentCore Gateway makes use of the Model Context Protocol (MCP) to standardize how brokers entry instruments. Changing present Lambda features into MCP endpoints requires minimal adjustments—primarily including device schemas and dealing with the MCP context. To make use of this performance, we convert our native instruments to Lambda features and create the instruments schema definitions to make these features discoverable by brokers:

# Authentic Lambda operate (simplified)
def web_search(key phrases: str, area: str = "us-en", max_results: int = 5) -> str:
    # web_search performance
        
def lambda_handler(occasion, context):
    if get_tool_name(occasion) == "web_search":
        question = get_named_parameter(occasion=occasion, identify="question")
        
        search_result = web_search(key phrases)
        return {"statusCode": 200, "physique": search_result}

The next code is the device schema definition:

{
        "identify": "web_search",
        "description": "Search the net for up to date info utilizing DuckDuckGo",
        "inputSchema": {
            "sort": "object",
            "properties": {
                "key phrases": {
                    "sort": "string",
                    "description": "The search question key phrases"
                },
                "area": {
                    "sort": "string",
                    "description": "The search area (e.g., us-en, uk-en, ru-ru)"
                },
                "max_results": {
                    "sort": "integer",
                    "description": "The utmost variety of outcomes to return"
                }
            },
            "required": [
                "keywords"
            ]
        }
    }

For demonstration functions, we construct a brand new Lambda operate from scratch. In actuality, organizations have already got completely different functionalities out there as REST providers or Lambda features, and this strategy allows you to expose present enterprise providers as agent instruments with out rebuilding them.

Configure safety with Amazon Bedrock AgentCore Gateway and combine with Amazon Bedrock AgentCore Identification

Amazon Bedrock AgentCore Gateway requires authentication for each inbound and outbound connections. Amazon Bedrock AgentCore Identification handles this by way of normal OAuth flows. After you arrange an OAuth authorization configuration, you’ll be able to create a brand new gateway and move this configuration to it. See the next code:

# Create gateway with JWT-based authentication
auth_config = {
    "customJWTAuthorizer": {
        "allowedClients": [cognito_client_id],
        "discoveryUrl": cognito_discovery_url
    }
}

gateway_response = gateway_client.create_gateway(
    identify="customersupport-gw",
    roleArn=gateway_iam_role,
    protocolType="MCP",
    authorizerType="CUSTOM_JWT",
    authorizerConfiguration=auth_config,
    description="Buyer Help AgentCore Gateway"
)

For inbound authentication, brokers should current legitimate JSON Web Token (JWT) tokens (from id suppliers like Amazon Cognito, Okta, and EntraID) as a compact, self-contained normal for securely transmitting info between events to entry Amazon Bedrock AgentCore Gateway instruments.

For outbound authentication, Amazon Bedrock AgentCore Gateway can authenticate to downstream providers utilizing AWS Identity and Access Management (IAM) roles, API keys, or OAuth tokens.

For demonstration functions, we’ve got created an Amazon Cognito person pool with a dummy person identify and password. To your use case, you must set a correct id supplier and handle the customers accordingly. This configure makes certain solely approved brokers can entry particular instruments and a full audit path is supplied.

Add Lambda targets

After you arrange Amazon Bedrock AgentCore Gateway, including Lambda features as device targets is simple:

lambda_target_config = {
    "mcp": {
        "lambda": {
            "lambdaArn": lambda_function_arn,
            "toolSchema": {"inlinePayload": api_spec},
        }
    }
}

gateway_client.create_gateway_target(
    gatewayIdentifier=gateway_id,
    identify="LambdaTools",
    targetConfiguration=lambda_target_config,
    credentialProviderConfigurations=[{
        "credentialProviderType": "GATEWAY_IAM_ROLE"
    }]
)

The gateway now exposes your Lambda features as MCP instruments that approved brokers can uncover and use.

Combine MCP instruments with Strands Brokers

Changing our agent to make use of centralized instruments requires updating the device configuration. We preserve some instruments native, reminiscent of product information and return insurance policies particular to buyer help that may possible not be reused in different use circumstances, and use centralized instruments for shared capabilities. As a result of Strands Brokers has a native integration for MCP tools, we are able to merely use the MCPClient from Strands with a streamablehttp_client. See the next code:

# Get OAuth token for gateway entry
gateway_access_token = get_token(
    client_id=cognito_client_id,
    client_secret=cognito_client_secret,
    scope=auth_scope,
    url=token_url
)

# Create authenticated MCP shopper
mcp_client = MCPClient(
    lambda: streamablehttp_client(
        gateway_url,
        headers={"Authorization": f"Bearer {gateway_access_token['access_token']}"}
    )
)

# Mix native and MCP instruments
instruments = [
    get_product_info,     # Local tool (customer support specific)
    get_return_policy,    # Local tool (customer support specific)
] + mcp_client.list_tools_sync()  # Centralized instruments from gateway

agent = Agent(
    mannequin=mannequin,
    instruments=instruments,
    hooks=[memory_hooks],
    system_prompt=SYSTEM_PROMPT
)

Check the improved agent

With the centralized instruments built-in, our agent now has entry to enterprise capabilities like guarantee checking:

# Check internet search utilizing centralized device  
response = agent("How can I repair Lenovo ThinkPad with a blue display screen?")
# Agent makes use of web_search from AgentCore Gateway

The agent seamlessly combines native instruments with centralized ones, offering complete help capabilities whereas sustaining safety and entry management.

Nonetheless, we nonetheless have a major limitation: our complete agent runs regionally on our growth machine. For manufacturing deployment, we want scalable infrastructure, complete observability, and the flexibility to deal with a number of concurrent customers.

Within the subsequent part, we deal with this by deploying our agent to Amazon Bedrock AgentCore Runtime, reworking our native prototype right into a production-ready system with Amazon Bedrock AgentCore Observability and computerized scaling capabilities.

Deploy to manufacturing with Amazon Bedrock AgentCore Runtime

With the instruments centralized and secured, our closing main hurdle is manufacturing deployment. Our agent presently runs regionally in your laptop computer, which is good for experimentation however unsuitable for actual clients. Manufacturing requires scalable infrastructure, complete monitoring, computerized error restoration, and the flexibility to deal with a number of concurrent customers reliably.

Amazon Bedrock AgentCore Runtime transforms your native agent right into a production-ready service with minimal code adjustments. Mixed with Amazon Bedrock AgentCore Observability, it supplies enterprise-grade reliability, computerized scaling, and complete monitoring capabilities that operations groups want to keep up agentic purposes in manufacturing.

Our structure will appear like the next diagram.

Minimal code adjustments for manufacturing

Changing your native agent requires including simply 4 traces of code:

# Your present agent code stays unchanged
mannequin = BedrockModel(model_id="us.anthropic.claude-3-7-sonnet-20250219-v1:0")
memory_hooks = CustomerSupportMemoryHooks(memory_id, memory_client, actor_id, session_id)
agent = Agent(
    mannequin=mannequin,
    instruments=[get_return_policy, get_product_info],
    system_prompt=SYSTEM_PROMPT,
    hooks=[memory_hooks]
)

def invoke(payload):
    user_input = payload.get("immediate", "")
    response = agent(user_input)
    return response.message["content"][0]["text"]

if __name__ == "__main__":

BedrockAgentCoreApp routinely creates an HTTP server with the required /invocations and /ping endpoints, handles correct content material varieties and response codecs, manages error dealing with in accordance with AWS requirements, and supplies the infrastructure bridge between your agent code and Amazon Bedrock AgentCore Runtime.

Safe manufacturing deployment

Manufacturing deployment requires correct authentication and entry management. Amazon Bedrock AgentCore Runtime integrates with Amazon Bedrock AgentCore Identification to offer enterprise-grade safety. Utilizing the Bedrock AgentCore Starter Toolkit, we are able to deploy our utility utilizing three easy steps: configure, launch, and invoke.

In the course of the configuration, a Docker file is created to information the deployment of our agent. It incorporates details about the agent and its dependencies, the Amazon Bedrock AgentCore Identification configuration, and the Amazon Bedrock AgentCore Observability configuration for use. In the course of the launch step, AWS CodeBuild is used to run this Dockerfile and an Amazon Elastic Container Registry (Amazon ECR) repository is created to retailer the agent dependencies. The Amazon Bedrock AgentCore Runtime agent is then created, utilizing the picture of the ECR repository, and an endpoint is generated and used to invoke the agent in purposes. In case your agent is configured with OAuth authentication by way of Amazon Bedrock AgentCore Identification, like ours can be, you additionally have to move the authentication token in the course of the agent invocation step. The next diagram illustrates this course of.

The code to configure and launch our agent on Amazon Bedrock AgentCore Runtime will look as follows:

from bedrock_agentcore_starter_toolkit import Runtime

# Configure safe deployment with Cognito authentication
agentcore_runtime = Runtime()

response = agentcore_runtime.configure(
    entrypoint="lab_helpers/lab4_runtime.py",
    execution_role=execution_role_arn,
    auto_create_ecr=True,
    requirements_file="necessities.txt",
    area=area,
    agent_name="customer_support_agent",
    authorizer_configuration={
        "customJWTAuthorizer": {
            "allowedClients": [cognito_client_id],
            "discoveryUrl": cognito_discovery_url,
        }
    }
)

# Deploy to manufacturing
launch_result = agentcore_runtime.launch()

This configuration creates a safe endpoint that solely accepts requests with legitimate JWT tokens out of your id supplier (reminiscent of Amazon Cognito, Okta, or Entra). For our agent, we use a dummy setup with Amazon Cognito, however your utility can use an id supplier of your selecting. The deployment course of routinely builds your agent right into a container, creates the required AWS infrastructure, and establishes monitoring and logging pipelines.

Session administration and isolation

One of the crucial essential manufacturing options for brokers is correct session administration. Amazon Bedrock AgentCore Runtime routinely handles session isolation, ensuring completely different clients’ conversations don’t intervene with one another:

# Buyer 1 dialog
response1 = agentcore_runtime.invoke(
    {"immediate": "My iPhone Bluetooth is not working. What ought to I do?"},
    bearer_token=auth_token,
    session_id="session-customer-1"
)

# Buyer 1 follow-up (maintains context)
response2 = agentcore_runtime.invoke(
    {"immediate": "I've turned Bluetooth on and off but it surely nonetheless would not work"},
    bearer_token=auth_token,
    session_id="session-customer-1"  # Similar session, context preserved
)

# Buyer 2 dialog (fully separate)
response3 = agentcore_runtime.invoke(
    {"immediate": "Nonetheless not working. What's going on?"},
    bearer_token=auth_token,
    session_id="session-customer-2"  # Totally different session, no context
)

Buyer 1’s follow-up maintains full context about their iPhone Bluetooth concern, whereas Buyer 2’s message (in a distinct session) has no context and the agent appropriately asks for extra info. This computerized session isolation is essential for manufacturing buyer help situations.

Complete observability with Amazon Bedrock AgentCore Observability

Manufacturing brokers want complete monitoring to diagnose points, optimize efficiency, and preserve reliability. Amazon Bedrock AgentCore Observability routinely devices your agent code and sends telemetry information to Amazon CloudWatch, the place you’ll be able to analyze patterns and troubleshoot points in actual time. The observability information contains session-level monitoring, so you’ll be able to hint particular person buyer session interactions and perceive precisely what occurred throughout a help interplay. You need to use Amazon Bedrock AgentCore Observability with an agent of your selection, hosted in Amazon Bedrock AgentCore Runtime or not. As a result of Amazon Bedrock AgentCore Runtime routinely integrates with Amazon Bedrock AgentCore Observability, we don’t want further work to look at our agent.

With Amazon Bedrock AgentCore Runtime deployment, your agent is prepared for use in manufacturing. Nonetheless, we nonetheless have one limitation: our agent is accessible solely by way of SDK or API calls, requiring clients to write down code or use technical instruments to work together with it. For true customer-facing deployment, we want a user-friendly internet interface that clients can entry by way of their browsers.

Within the following part, we display the entire journey by constructing a pattern internet utility utilizing Streamlit, offering an intuitive chat interface that may work together with our production-ready Amazon Bedrock AgentCore Runtime endpoint. The uncovered endpoint maintains the safety, scalability, and observability capabilities we’ve constructed all through our journey from proof of idea to manufacturing. In a real-world state of affairs, you’ll combine this endpoint along with your present customer-facing purposes and UI frameworks.

Create a customer-facing UI

With our agent deployed to manufacturing, the ultimate step is making a customer-facing UI that clients can use to interface with the agent. Though SDK entry works for builders, clients want an intuitive internet interface for seamless help interactions.

To display a whole answer, we construct a pattern Streamlit-based web-application that connects to our production-ready Amazon Bedrock AgentCore Runtime endpoint. The frontend contains safe Amazon Cognito authentication, real-time streaming responses, persistent session administration, and a clear chat interface. Though we use Streamlit for rapid-prototyping, enterprises would usually combine the endpoint with their present interface or most well-liked UI frameworks.

The top-to-end utility (proven within the following diagram) maintains full dialog context throughout the classes whereas offering the safety, scalability, and observability capabilities that we constructed all through this publish. The result’s a whole buyer help agentic system that handles all the pieces from preliminary authentication to complicated multi-turn troubleshooting conversations, demonstrating how Amazon Bedrock AgentCore providers remodel prototypes into production-ready buyer purposes.

Conclusion

Our journey from prototype to manufacturing demonstrates how Amazon Bedrock AgentCore providers deal with the standard boundaries to deploying enterprise-ready agentic purposes. What began as a easy native buyer help chatbot reworked right into a complete, production-grade system able to serving a number of concurrent customers with persistent reminiscence, safe device sharing, complete observability, and an intuitive internet interface—with out months of customized infrastructure growth.

The transformation required minimal code adjustments at every step, showcasing how Amazon Bedrock AgentCore providers work collectively to resolve the operational challenges that usually stall promising proofs of idea. Reminiscence capabilities keep away from the “goldfish agent” drawback, centralized device administration by way of Amazon Bedrock AgentCore Gateway creates a reusable infrastructure that securely serves a number of use circumstances, Amazon Bedrock AgentCore Runtime supplies enterprise-grade deployment with computerized scaling, and Amazon Bedrock AgentCore Observability delivers the monitoring capabilities operations groups want to keep up manufacturing techniques.

The next video supplies an outline of AgentCore capabilities.

Able to construct your individual production-ready agent? Begin with our full end-to-end tutorial, the place you’ll be able to observe together with the precise code and configurations we’ve explored on this publish. For added use circumstances and implementation patterns, discover the broader GitHub repository, and dive deeper into service capabilities and finest practices within the Amazon Bedrock AgentCore documentation.

Concerning the authors

Maira Ladeira Tanke is a tech Lead for Agentic AI at AWS, the place she allows clients on their journey to develop autonomous AI techniques. With over 10 years of expertise in AI/ML, Maira companions with enterprise clients to speed up the adoption of agentic purposes utilizing Amazon Bedrock AgentCore and Strands Brokers, serving to organizations harness the ability of basis fashions to drive innovation and enterprise transformation. In her free time, Maira enjoys touring, enjoying along with her cat, and spending time along with her household someplace heat.