awslabs/agentcore-samples: A Sample Repository Mid-Migration
Amazon Bedrock Agentcore accelerates AI agents into production with the scale, reliability, and security, critical to real-world deployment.
At a glance
- What is it?
- The AgentCore samples repo collects Python and TypeScript examples for Runtime, Gateway, Memory, Identity, Policy and Evaluation. Its most important property right now is that it is switching CLIs, and part of the tree still depends on the old one.
- Who is it for?
- Adopt this repository if you are already committed to Amazon Bedrock AgentCore and want runnable examples of Runtime, Gateway, Memory, Identity, Policy and Evaluation rather than prose. Do not adopt it if you are still choosing an agent stack, or if you want a versioned library: there are no releases here, only a moving main branch, and the README states plainly that Starter Toolkit samples are in legacy/ and will be updated over the coming weeks.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What the samples repository is actually for
Amazon Bedrock AgentCore is an AWS service for running agents. This repository is not that service and not its SDK. It is a collection of examples and tutorials, organized so that you can find a working pattern for a specific capability instead of assembling one from API reference pages. The README frames the service as framework-agnostic and model-agnostic, and names Strands Agents, CrewAI, LangGraph and LlamaIndex as frameworks you can bring, with the claim that you deploy without rewriting code. The samples exist to demonstrate that claim per capability rather than in the abstract. The audience is narrow and specific: engineers who have already decided to run agents on AgentCore and now need to see how Runtime, Gateway, Identity, Memory, Tools, Observability, Evaluation and Policy are wired together in practice. If you are still comparing agent hosting options, this repository will not help you decide, because every path through it assumes the AWS service underneath.
How the repository is laid out, and why the layout matters
The tree is split by intent. getting-started/ holds first-agent material in python/ and typescript/ variants. features/ holds one directory per capability: Runtime for the serverless runtime, Gateway for turning APIs, Lambda functions and services into MCP-compatible tools, Identity, Memory, Tools (Code Interpreter, Browser Tool, Web Search Tool), Observability over OpenTelemetry, Evaluation with built-in and custom evaluators for on-demand and online evaluation, and Policy using Cedar. end-to-end/ holds complete applications that combine several capabilities, with deployment instructions, architecture diagrams and testing guides. integrations/ splits into identity-providers (Okta, Entra, Cognito), observability (Grafana, Datadog, Dynatrace), data-platforms, and ux-examples (Streamlit, AG-UI). infrastructure-as-code/ carries CloudFormation, AWS CDK and Terraform templates for provisioning AgentCore resources. blueprints/ holds full-stack reference applications with authentication and business logic. That division is the useful part. A capability question sends you to features/; a provisioning question sends you to infrastructure-as-code/; a question about whether this fits an existing Okta tenant sends you to integrations/identity-providers/.
The CLI migration is the first thing to understand
The README states that the repository is transitioning from the Bedrock AgentCore Starter Toolkit to the AgentCore CLI, and that samples still depending on the Starter Toolkit live in legacy/ and will be updated over the coming weeks. A MIGRATION.md file is referenced for the old-path to new-path mapping, and the workshops section is marked deprecated with an explicit recommendation to use the AgentCore CLI instead of the Starter Toolkit CLI. The AgentCore CLI is published as @aws/agentcore and, per the README, supports Strands, LangGraph, LangChain, Google ADK, OpenAI Agents and a bring-your-own path, plus local development with hot reload, built-in evaluations and gateway support. This is the single most consequential fact about the repository today. Two samples that look equivalent may target different toolchains, and the one under legacy/ is the one that will change under you. Treat the directory name as a compatibility signal, not a historical footnote.
Getting an agent running: what the material actually specifies
The concrete entry point given is getting-started/, described as the fastest way to create, develop and deploy agents on AgentCore, using the AgentCore CLI. The README points to the CLI repository at github.com/aws/agentcore-cli and names the package @aws/agentcore. The Python SDK lives in a separate repository, aws/bedrock-agentcore-sdk-python, and the service documentation is at docs.aws.amazon.com/bedrock-agentcore/. Those three links are the ones to follow before writing code: the CLI for scaffolding and deployment, the SDK for the programmatic surface, the docs for the service contract. Beyond the package name and the repository links, the supplied material does not give install commands, subcommands, or configuration keys for the CLI, and it does not list environment variables or a config file format for the samples. Rather than guess at them, read the getting-started sample for your language and follow its own instructions. What the README does establish is that local development with hot reload is a CLI feature, which is the reason to prefer it over the Starter Toolkit for iteration.
Where this repository stops being the right tool
Three limits are visible from the material alone. First, there are no retrieved releases, so there is no tagged version to pin. You are reading main, and main is explicitly in motion: the README says legacy/ samples will be updated over the coming weeks. A sample you vendor today may be rewritten. Second, the samples are examples, not a library. Nothing here promises a stable interface, and copying a pattern out of features/ does not give you the maintenance commitment that the Python SDK repository implies. Third, the repository is AWS-specific by construction. The framework-agnostic and model-agnostic claims describe what you can bring to AgentCore, not what AgentCore runs on. If your constraint is running agents inside your own VPC with no managed control plane, or on a cloud other than AWS, every sample here assumes infrastructure you have decided not to use, and the useful content collapses to the framework examples themselves, which you would get from Strands, LangGraph or LlamaIndex directly.
Alternatives, and the real difference in approach
The clearest alternative is the Python SDK repository, aws/bedrock-agentcore-sdk-python. The split is deliberate: the SDK is the interface you import, and this repository is the set of worked examples that show how to use it. If you need a stable dependency in your build, the SDK is the thing to depend on and these samples are the thing to read once. A second alternative is the AgentCore CLI repository itself, github.com/aws/agentcore-cli. The CLI scaffolds and deploys; the samples show what the scaffolded project looks like once it is doing something real, such as exposing a Lambda function through Gateway as an MCP tool or attaching a Cedar policy. A third alternative is simply the AWS documentation at docs.aws.amazon.com/bedrock-agentcore/, which is the authoritative description of each capability. The difference in approach is that documentation describes every option and samples choose one. If you want to know what is possible, read the docs. If you want to know what a working configuration looks like before you commit to one, read the samples and then verify against the docs.
Maintenance cost and the licence position
The repository is licensed Apache-2.0, which permits commercial use and modification and includes an explicit patent grant, with the usual requirement to preserve notices and state changes. That is a permissive licence, but it says nothing about support, and the absence of releases means there is no version boundary at which a compatibility promise begins. The practical maintenance cost is therefore the cost of tracking main. If you copy a sample into your own codebase, you own it from that moment: the migration from the Starter Toolkit to the AgentCore CLI is exactly the kind of change that will not reach you automatically. The mitigation is structural rather than procedural. Keep the sample's deployment configuration in infrastructure-as-code/ or blueprints/ form where the repository provides it, so the diff against upstream is readable, and record which sample and which directory you started from. This is not legal advice; if the patent grant or notice requirements matter to your organization, have counsel read the LICENSE file rather than this paragraph.
Who should take this repository seriously
The strongest fit is a team that has already chosen AgentCore, has a specific capability to wire up, and wants to see it done before designing their own version. Gateway is the obvious case: converting an existing API or Lambda function into an MCP-compatible tool is a task with a right shape and many wrong ones, and features/ exists to show the right one. Identity is the second, because the integrations/identity-providers/ directory covers Okta, Entra and Cognito, which is where real deployments usually stall. The weakest fit is anyone treating this as a starter template to fork wholesale. It is a catalogue with a migration in progress, and the README says so in its own words. Read MIGRATION.md first, pick the sample that matches your capability, confirm it is not under legacy/, and check whether an infrastructure-as-code/ or blueprints/ variant exists for it before you write deployment code by hand.
Editorial conclusion
Adopt this repository if you are already committed to Amazon Bedrock AgentCore and want runnable examples of Runtime, Gateway, Memory, Identity, Policy and Evaluation rather than prose. Do not adopt it if you are still choosing an agent stack, or if you want a versioned library: there are no releases here, only a moving main branch, and the README states plainly that Starter Toolkit samples are in legacy/ and will be updated over the coming weeks. Before copying anything, open MIGRATION.md, check whether the sample you want lives under legacy/ or under getting-started/, and confirm it targets the AgentCore CLI rather than the Starter Toolkit. Then read the sample's own deployment instructions, because this repository is a collection of examples, not a supported product with an upgrade path.
Community notes