Building a Full-Stack AI Agent on Amazon Bedrock AgentCore

This is the first in a series of posts documenting the architecture, implementation, and lessons learned from building the AWS Briefing Agent - a personalised AWS assistant deployed on Amazon Bedrock AgentCore Runtime.

• Part 1: Building a Full-Stack AI Agent on Bedrock AgentCore
• Part 2: Data Ingestion: RSS Feeds, Knowledge Base, S3 Vectors, and Metadata Filtering
• Part 3: Strands Agents + AgentCore Runtime - a perfect match
• Part 4: Adding Memory to the Agent
• Part 5: Experimenting with API Gateway
• Part 6: Observability and Evaluations
• Part 7: Third Party Integrations - Identity, Gateway and Slack Notifications

Why build an agent?

The last few years have seen a rapid shift from Generative to Agentic AI. It began with assistants that would take in a prompt and return a response - impressive at the time, but still largely reactive and reliant on human input. We then saw the emergence of early AI agents that could break down tasks into smaller steps and execute them independently. Over the past year, this has evolved into fully autonomous multi-agent systems capable of completing complex tasks with minimal or even no human supervision.

The shift is accelerating quickly. Gartner predicts that by 2028, more than a third of all enterprise software apps will include Agentic AI, and at least 15% of day-to-day work decisions will be made autonomously by AI agents. For organisations, the question is no longer whether agents will become part of enterprise systems, but how to build them securely, reliably and operate them at scale.

The goal of this blog series is to build out an agentic application using various features of Amazon Bedrock AgentCore, to help better understand the AgentCore capabilities and showcase how they can be used together.

Why AgentCore Runtime?

Amazon Bedrock AgentCore is an AWS service that has been designed specifically for the task of hosting agents. A common saying I keep on hearing is that Bedrock AgentCore is to agentic applications what AWS Lambda is to event driven applications.

At the heart is AgentCore Runtime, which provides the secure runtime for executing the agent code. AgentCore Runtime provides session-based isolation, where every session is assigned a dedicated Firecracker microVM with isolated CPU, memory and filesystem resources (the same lightweight virtualisation technology that underpins AWS Lambda and AWS Fargate). When the session finishes, the LLM's state information is copied to long-term memory and the entire microVM is destroyed. There is no shared state between sessions, which prevents any cross-session data leakage.

AgentCore Runtime is framework-agnostic and supports all popular frameworks such as Strands Agents, LangGraph and CrewAI. It also works with any LLM, such as models offered by Amazon Bedrock, Anthropic Claude, Google Gemini and OpenAI or even hosted on-premises. It supports long sessions up to 8 hours, which means it can handle complex multi-step tasks or time-consuming background processes. Unlike traditional compute services that charge for pre-allocated resources, AgentCore Runtime uses consumption-based pricing where you only pay for active CPU and memory usage. With this, I/O wait and idle time is free, and you're only charged for actual resource consumption calculated at per-second increments. The runtime automatically scales from zero to thousands of concurrent sessions on demand, with no capacity planning needed, and includes reliability features like checkpointing to recover gracefully from interruptions.

AWS Briefing Agent Architecture

A high-level architecture overview of the AWS Briefing Agent is shown below:

• AWS Briefing Agent Client is a next.js static site hosted on AWS Amplify Hosting. It integrates directly with Amazon Cognito using the amazon-cognito-identity-js SDK, implementing a full sign-in, sign-up and email verification flow.

• AWS Briefing Agent itself is a Python application built with the Strands Agents SDK and deployed to AgentCore Runtime as a Docker container. The @aws/agentcore CLI handles the full deployment lifecycle. When you run agentcore deploy, the CLI triggers AWS CodeBuild to build the Docker image (ARM64), pushes it to Amazon ECR, and deploys it to AgentCore Runtime.

• AgentCore Memory provides persistent user knowledge across sessions using two built-in memory strategies. The SEMANTIC memory strategy extracts factual information and knowledge from conversations that have taken place e.g. that a user works with Lambda and EKS. The USER_PREFERENCE memory strategy identifies and extracts user preferences from conversations e.g. that the user prefers technical deep dives. The agent retrieves relevant memory records at the start of each invocation and injects them as context, enabling personalised briefings from the first message of a new session.

• AgentCore Observability is used to instrument all Bedrock API calls, tool invocations and memory operations. This is carried out entirely by setting enableOtel: true in the runtime config and using the opentelemetry-instrument wrapper command. Spans show up in CloudWatch Transaction Search and the CloudWatch GenAI Observability dashboard is populated with the sessions and traces, and provides the abiliyty to drill into individual invocations.

• AgentCore Evaluations is configured to run online quality assessments against agent responses using built-in evaluators for Helpfulness, Goal Success Rate, and Correctness. These are shown in the front-end to give an indication on how well the agent is performing for each user.

• Bedrock Knowledge Base is created and backed by Amazon S3 Vectors that stores all announcements, blog posts and security bulletins. An ingestion Lambda runs every 6 hours that writes each item as a .txt file alongside a metadata.json file to the S3 bucket, before triggering a Knowledge Base sync. The agent queries the KB via the Strands retrieve tool with metadata filters for date ranges and service names, enabling questions like "what's new in Bedrock this week?"

• AgentCore Gateway exposes a managed MCP (Model Context Protocol) endpoint that the agent connects to at runtime for tool discovery. The Slack integration is defined as an OpenAPI spec pointing at the Slack chat.postMessage API, and is registered as a Gateway target. The agent discovers available tools dynamically via the MCP protocol. The Gateway handles authentication and credential injection for this integration with Slack, attaching the stored bot token as a Bearer header on outbound Slack API calls.

• AgentCore Identity stores the Slack bot token as an API key credential in its token vault (encrypted at rest via Secrets Manager). When the agent calls the tool to send a briefing to Slack, AgentCore Identity retrieves the bot token and injects it into the outbound request automatically. The agent code never sees or handles the token directly.

• AgentCore Registry is a governed catalog for agents, MCP servers, tools, skills, and custom resources. Teams can publish resources, control access through approval workflows, and enable both humans and AI agents to discover tools using semantic and keyword search. Once the Slack integration was working, the briefing agent and the Slack tool where registered in the AgentCore Registry. This makes the tool discoverable by other agents in the organisation.

AWS Briefing Agent in Action

We create a new user and login to the home screen for the AWS Briefing Agent front end. The first time we use the agent, we are asked to provide information about our interests and the type of briefing style we are interested in. These get added to memory, so that the agent can personalise its responses:

We can provide the details of the services we are most interested to the agent. At this point, the agent will pull back the top announcements that it has retrieved from the Knowledge Base, and display them in a briefing summary.

We have also integrated with Slack through Gateway. This means we can ask the Briefing Agent to post the details to our Slack channel:

This means that when we go to our Slack channel, we can see a new message with our briefing, alongside all the links we can click to take us to the original blog posts and announcement articles.