Bedrock AgentCore SDK for Python: What the Runtime Wrapper Actually Does
Python SDK for transforming any AI agent into a production-ready application. Framework-agnostic primitives for runtime, memory, authentication, and tools with AWS-managed infrastructure.
At a glance
- What is it?
- The SDK is a thin Python layer that turns a local agent loop into an HTTP service on AWS-managed compute. It is worth adopting if you already run on AWS and want session isolation without writing a Dockerfile; it is the wrong tool if you need to self-host or want the platform to own your agent's control flow.
- Who is it for?
- Adopt it if your agent already runs on AWS, your framework exposes a streaming interface, and you want session-isolated compute without owning the container or the scaling policy. Do not adopt it if you need to run the agent outside AWS, or if you want the platform to decide how your agent reasons.
- 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 4 days 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
The gap between a working agent loop and a served endpoint
A local agent is a loop: take input, call a model, call tools, return text. Turning that loop into something multiple users can hit concurrently means writing an HTTP server, deciding how to isolate one session's state from another's, adding auth, and packaging the whole thing into an image that a scheduler can scale. None of that is agent logic, and all of it is the part that delays a demo from becoming a deployment.
This SDK targets that specific gap. The README frames it as deploying a local agent "with zero infrastructure," and the code sample is deliberately small: import BedrockAgentCoreApp, decorate one function with @app.entrypoint, call app.run(). The handler receives a request dict, pulls out a prompt, and yields events from an agent stream. The SDK does not prescribe the agent. The sample imports Strands, but the README states the same wrapper works with LangGraph, CrewAI, Autogen, or a custom framework.
That audience is narrow and specific. It is for teams already committed to AWS who have agent code they like and do not want to rewrite it against a new abstraction. If you are still choosing a framework, this SDK gives you no reason to choose one, because it deliberately has no opinion about the reasoning layer.
One entrypoint, two protocol front ends
The mechanism is a decorator plus a runtime. BedrockAgentCoreApp collects the function registered under @app.entrypoint and serves it. The handler is an async generator: it yields events rather than returning a single response, which is what lets the platform stream tokens back to the caller as the agent produces them.
The AG-UI path makes the transport contract explicit. The README states that a single entrypoint handler is served over both SSE at POST /invocations and WebSocket at /ws. That is the concrete detail worth remembering: you write the agent once, and the SDK exposes it on two transports. The serve_ag_ui(agui_agent) helper is a one-liner for frameworks that already expose a .run() method. The decorator form, using AGUIApp and yielding RunStartedEvent and RunFinishedEvent from ag_ui.core, is for agents that need to emit protocol events themselves.
A2A is the second front end, and the README states it works with any framework providing an a2a-sdk AgentExecutor, naming Strands, LangGraph, and Google ADK. Note what is absent: the README does not document a shared internal abstraction that both protocols compile down to. The two paths are presented as separate surfaces over the same handler shape. That is a reasonable design, but it means protocol-specific behaviour lives in your handler, not in the SDK.
Installing it and getting an agent onto the platform
The Python package is bedrock-agentcore on PyPI, and the AG-UI support is an extra: pip install "bedrock-agentcore[ag-ui]". That extra pulls in ag_ui.core, which is why the decorator form imports RunAgentInput and the run lifecycle events from it. If you skip the extra and try the AGUIApp import, the dependency is not there.
Deployment does not go through Python. The README recommends the AgentCore CLI, installed from npm: npm i -g @aws/agentcore. From there the documented sequence is agentcore create --name MyAgent --defaults, then cd MyAgent, then agentcore deploy. The CLI handles packaging, infrastructure provisioning, and deployment. The --defaults flag is what makes the create step non-interactive, which matters if you are scripting it in CI.
The CLI generates AWS CDK underneath. The README describes the CDK route as the advanced option, for teams that want to customize the generated project directly or work against the L1 constructs in aws-cdk-lib.aws_bedrockagentcore. So the real deployment artifact is a CDK app, and the CLI is a generator plus a deploy wrapper around it. If your organization already has CDK conventions, the honest path is to generate once and then own the synthesized stack rather than re-running create.
Where the wrapper stops being helpful
The SDK is framework-agnostic in the sense that it does not care what produces your events. It is not framework-agnostic in the sense of adapting between them. The handler signature is a request dict in, an async generator out. The README's own sample adds a manual type check, raising ValueError if the prompt is not a string, and the surrounding note says to validate agent input before forwarding it to a framework. That instruction is doing real work: the SDK does not validate for you, and a non-string prompt reaching a framework is your bug, not the platform's.
The harder limitation is the hosting model. Runtime is described as secure, session-isolated compute on AWS-managed infrastructure. Session isolation is the feature; it is also the constraint. There is no documented path in the supplied material for running this handler on your own Kubernetes cluster or on another cloud. The other services in the list (Memory, Gateway, Code Interpreter, Browser, Identity, Observability) are AWS services the SDK talks to, not libraries you can point at a self-hosted equivalent.
There is also a versioning cost that the release cadence implies. Releases at v1.20.0, v1.21.0, and v1.22.0 land within roughly two weeks of each other in August 2026. Frequent minor releases on a 1.x line are normal for an actively developed SDK, but they mean the surface you pin is moving. Treat the pinned version as part of your deployment artifact, not an incidental dependency.
How this differs from a self-hosted agent server
The obvious alternative is running your own server: FastAPI or similar, your agent inside it, a container image, and a scheduler you operate. The difference is not the HTTP layer, which is trivial either way. The difference is who owns session isolation and scaling.
With a self-hosted server, you decide how sessions map to processes or threads, you write the auth middleware, and you configure the autoscaler. You also get to run it anywhere, including on-premises, and you can attach a debugger to a live process. With AgentCore, the README states there are no servers, containers, or scaling concerns to manage, and that auth, memory, and observability are built in. You trade operational control for operational absence.
A second alternative is staying inside your framework's own deployment story. Several of the named frameworks ship their own serving or hosting options. Choosing that route keeps you on one vendor's abstractions end to end, which is simpler until you need a capability the framework does not have. The AgentCore SDK's pitch is that it sits under the framework rather than replacing it: the README's bullet is "Keep your agent logic." Whether that holds depends on how cleanly your framework exposes a streaming interface, which is exactly the thing to test before you commit.
Licence, maintenance, and what you are actually signing up for
The repository is Apache-2.0. That covers the SDK source. It does not cover the AWS services the SDK calls, which are billed and governed by AWS terms, and it does not cover the npm-distributed CLI, which lives in a separate repository. Three artefacts, three sets of terms. This is not legal advice; read the licence file and the service terms yourself before you build a compliance story on the Apache-2.0 badge.
Maintenance cost has two parts. The Python side is a pin and an upgrade cadence, and the release history shows that cadence is fast. The infrastructure side is the generated CDK. Once agentcore create has run, you own a CDK project, and CDK projects accrue drift: construct versions move, security patches land, and the generated code does not regenerate itself. Teams that treat the CLI output as disposable scaffolding tend to be surprised by this.
There is also a support boundary worth naming. The README links to AWS documentation, a samples repository, a Discord server, and the Boto3 control-plane SDK. The Boto3 link is a reminder that the control plane (creating and configuring AgentCore resources) is a different API surface from this runtime SDK. If you need to manage resources programmatically rather than through the CLI, that is where you will end up, and it is a separate dependency to track.
A narrow fit, stated plainly
This SDK is a hosting adapter. It takes an agent you already have and puts it behind a managed endpoint with session isolation, auth, and tracing. The entrypoint decorator, the async generator contract, the dual SSE and WebSocket serving for AG-UI, and the A2A path via a2a-sdk AgentExecutor are the whole of the mechanism visible in the supplied material. There is no orchestration layer, no memory abstraction you can swap out, and no documented way to run the runtime piece off AWS.
That makes the adoption decision mostly a question about your existing constraints rather than about the SDK's features. If you are on AWS, your framework streams, and the thing blocking you is infrastructure, the wrapper is small enough to try in an afternoon. If any of those three is false, the SDK adds a dependency without removing work.
Editorial conclusion
Adopt it if your agent already runs on AWS, your framework exposes a streaming interface, and you want session-isolated compute without owning the container or the scaling policy. Do not adopt it if you need to run the agent outside AWS, or if you want the platform to decide how your agent reasons. Before committing, verify three things in your own account: that bedrock-agentcore installs against your Python version, that the CLI's generated CDK matches your networking and IAM constraints, and that your framework's streaming API maps cleanly onto the entrypoint's async generator, because the SDK does not adapt that for you.
Community notes