Why Isn't the AWS Blocks Agent Built on AgentCore? What the Repository Reveals About What's Next

Since AWS Blocks entered public preview in June 2026, I have been making small contributions to the open-source project.

• AWS Blocks on GitHub

In my previous post on AWS Blocks, Amplify, and App Studio, I looked at how these tools differ and what each is trying to achieve. While revisiting the Agent Block, one detail caught my attention:

The AWS Blocks Agent is not currently running on Amazon Bedrock AgentCore.

At a glance, it is easy to assume the relationship looks like this:

AWS Blocks
  └─ Agent
       └─ Amazon Bedrock AgentCore

Enter fullscreen mode Exit fullscreen mode

But that is not how the current implementation works—at least not on main as of August 12, 2026.

Then the story gets interesting.

When I wondered whether an agent should simply use AgentCore directly, I found a fairly concrete set of pull requests that proposes moving the Agent Block’s execution model to AgentCore Runtime.

I contribute to AWS Blocks, but this is not an AWS statement or a roadmap. It is my reading of the public documentation and the open-source repository, from the perspective of both a user and a contributor.

TL;DR

• The Agent Block on the current main branch does not run on AgentCore Runtime.
• It combines the Strands Agents SDK with AsyncJob, Realtime, FileBucket, and DistributedTable.
• A five-PR stack proposes migrating the Agent Block’s execution model to AgentCore Runtime.
• As of August 12, 2026, all five migration PRs are still draft and unmerged. They are not an official roadmap.
• A separate open PR proposes Blocks for AgentCore Memory, Gateway, and Identity.

So the most accurate conclusion today is this: AWS Blocks Agent is not AgentCore today, but the repository contains concrete proposals for bringing the two together.

The Agent Block today is not AgentCore

Let’s start with the implementation on main.

The Agent Block uses the Strands Agents SDK. But it is not a standalone agent runtime; it composes several Blocks to handle execution, streaming, and persistence.

At a high level, the structure looks like this:

Agent
├─ Strands Agents SDK
├─ AsyncJob
├─ Realtime
├─ FileBucket
└─ DistributedTable

Enter fullscreen mode Exit fullscreen mode

The current CDK implementation creates these Blocks internally:

• AsyncJob executes the agent work.
• Realtime streams output back to the browser.
• FileBucket stores session snapshots.
• DistributedTable persists conversations and messages.

The AgentBase implementation follows the same pattern: an AsyncJob handler runs a Strands agent and publishes generated chunks through Realtime.

When deployed to AWS, this maps primarily to Lambda, SQS, API Gateway WebSocket, S3, and DynamoDB.

That is a very AWS Blocks-style design. You define one Agent, while the queue, WebSocket connection, storage, and tables needed behind the scenes are assembled for you.

Why isn’t it AgentCore already?

The public repository does not let us state with certainty why AgentCore was not the original execution layer, so I do not want to invent a reason.

What we can see is that the current Agent Block is built by composing existing Blocks. That is consistent with the AWS Blocks model: a Block can compose other Blocks to provide a higher-level capability.

At the same time, AgentCore Runtime is purpose-built for running agents in production. It provides isolated sessions, extended execution, and streaming. It also supports bidirectional streaming over WebSocket.

AgentCore as a whole also offers services such as Memory, Gateway, Identity, Observability, Browser, and Code Interpreter.

So it is natural for an AWS user to ask:

If I am building an agent, why not start with AgentCore?

I had the same reaction.

The repository points to an AgentCore migration

The most direct signal is PR #250: feat(bb-agent): migrate streaming execution to AgentCore Runtime (1/5).

The PR describes a limitation of the current Lambda + SQS + Realtime design: Lambda’s execution limit constrains long-running, multi-step agents. It proposes AgentCore Runtime—whose sessions can run for up to eight hours and which has native streaming—as the execution layer instead.

However, #250 is deliberately only the foundation. Its own description says that it does not complete the browser-to-AgentCore path. Direct browser streaming arrives in the next PR.

The work is split into five stacked PRs:

#250 Foundation: move agent execution toward AgentCore Runtime
  ↓
#251 Browser-direct WebSocket streaming and verified identity
  ↓
#252 README and API documentation updates
  ↓
#261 Server-resolved tool context from verified JWT claims
  ↓
#262 Grant other Blocks' permissions to the AgentCore Runtime role

Enter fullscreen mode Exit fullscreen mode

• #250: AgentCore Runtime migration foundation
• #251: browser-direct WebSocket streaming
• #252: documentation for the AgentCore streaming API
• #261: tool context from verified JWT claims
• #262: propagate other Blocks’ permissions to the runtime role

PR #251 is particularly revealing. Moving the execution layer in #250 is not enough by itself: the browser still has a Lambda-mediated path. #251 proposes connecting the browser directly to AgentCore Runtime over WebSocket, allowing agent output to stream without passing through Lambda.

This is not merely a case of “using AgentCore.” The PR stack works through streaming, authentication, tool context, and IAM permissions—in other words, the details of how AgentCore could sit behind the AWS Blocks developer experience.

As of August 12, 2026, all five PRs are open drafts and have not been merged. That is evidence of a concrete implementation proposal, not confirmation that AWS Blocks will adopt it as-is.

There is also a separate AgentCore-Blocks proposal

Another direction appears in PR #122, which proposes three new Building Blocks:

bb-agentcore-memory
bb-agentcore-gateway
bb-agentcore-identity

Enter fullscreen mode Exit fullscreen mode

This is different from replacing the Agent Block’s execution layer. Instead, it would expose individual AgentCore capabilities through the AWS Blocks development model.

PR #122 is open and unmerged as of August 12, 2026, so it is not a roadmap either. Still, it is interesting to see both directions represented in working proposals:

• Move the Agent Block’s execution layer to AgentCore Runtime.
• Make individual AgentCore services available as Blocks.

The important idea: replace the inside of the Agent Block

The question I am interested in is not whether users should choose AWS Blocks Agent or AgentCore.

Instead, the better outcome may be to preserve the experience and responsibility of the AWS Blocks Agent while replacing its execution layer with AgentCore.

Conceptually, that would look like this:

Current main branch

new Agent(...)
  └─ Strands Agents SDK
       ├─ AsyncJob
       ├─ Realtime
       ├─ DynamoDB / S3
       └─ Bedrock model


Direction proposed by the PRs

new Agent(...)
  └─ Strands Agents SDK
       ├─ AgentCore Runtime
       ├─ DynamoDB / S3 conversation and history persistence
       └─ Bedrock model

Enter fullscreen mode Exit fullscreen mode

Developers would still start with new Agent(...) and define an agent with tools, conversation history, and human-in-the-loop behavior. But the execution layer—especially long-running work and browser streaming—could move to AgentCore Runtime.

That is how I read the relationship between #250 and #251: #250 introduces AgentCore Runtime as the execution foundation, while #251 adds the direct WebSocket path from the browser to the runtime.

It would not be an invisible substitution. #250 includes changes that affect existing usage, including the introduction of streamSSE() and the removal of the Realtime API surface. But it could preserve the main value of Blocks: developers would not need to assemble Lambda, SQS, and API Gateway WebSocket themselves every time they create an agent.

Using an AgentCore-backed agent without having to think about AgentCore

One way I think about AWS Blocks is:

You can understand the infrastructure when you need to, but you do not have to start there.

The same could apply to AgentCore.

You define an Agent. Under the hood, AWS Blocks could provision AgentCore Runtime, configure authentication and IAM roles, and provide the browser streaming path. If needed, you could still drop down into the CDK layer and tune the underlying resources.

In that world, the developer is not choosing between AgentCore and Blocks. They keep using the AWS Blocks Agent abstraction while its implementation evolves to use AgentCore Runtime.

That feels much closer to the AWS Blocks philosophy.

Why this migration would be very Blocks-like

The current Agent Block composes several AWS services and Blocks to implement an agent. If a more suitable AWS service becomes available for part of that job, the implementation behind the Block can change.

What developers want is not necessarily this collection of resources:

SQS
Lambda
API Gateway WebSocket
DynamoDB
S3

Enter fullscreen mode Exit fullscreen mode

They want an Agent.

The migration proposal is not completely transparent—existing applications may need code changes—but it is a good illustration of a Building Block separating the capability an application needs from the AWS services used to implement it at a given time.

A necessary caveat: this is not available today

This point matters.

As of August 12, 2026, the five PRs that propose the AgentCore Runtime migration are all drafts. The Agent Block on main still uses the Strands Agents SDK together with AsyncJob, Realtime, and the other Blocks described above.

So it would be inaccurate today to say that “AWS Blocks Agent runs on AgentCore.”

An open-source pull request is also not the same thing as an AWS product roadmap. The design may change substantially, or the PRs may never merge.

Everything in this post about what comes next is an interpretation of public proposals, not a statement of future plans.

Open source lets us see a product in motion

This is one of the most interesting things about AWS Blocks.

With many managed AWS services, we only see a new architecture once it is announced. AWS Blocks is open source, so we can also see the current implementation, the problems being identified, and the proposed changes that are being discussed.

Contributors can even participate in that process.

For me, that is part of the appeal of AWS Blocks: it is not only a framework to use, but also a framework whose evolution you can follow.

Closing thoughts

My initial reaction was simple: “Oh, the Agent Block is not AgentCore.”

Then I wondered whether the implementation inside AWS Blocks Agent could move closer to AgentCore instead.

Following the repository revealed a stack of PRs proposing exactly that direction. It is too early to call it the future of AWS Blocks, but it does make the design question visible in a useful way.

The most interesting part is that the initial discomfort—”Why isn’t this AgentCore?”—has appeared in the repository as a concrete design problem with a concrete proposed solution.

That is one of the pleasures of following an open-source project in public preview. I will be watching to see what happens to these AgentCore migration PRs next.